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Executive  Summary 


The  future  has  arrived;  it's  just  not  evenly  distributed. 

-  William  Gibson 

To  complete  its  missions,  the  Department  of  Defense  (DoD)  must 
continually  reinvent  itself  as  threats  and  technologies  shift  and 
evolve.  Advanced  Systems  &  Concepts  (AS&C)  is  tasked  with 
evaluating  new  trends,  capabilities,  and  practices  for  maintaining 
DoD  superiority  while  responding  to  new  challenges.  But  even  as 
emerging  capabilities  are  tracked  and  assessed,  DoD’s  design  and 
acquisition  methods  are  ill-suited  to  keep  pace  with  accelerating 
shifts  in  technology,  particularly 
software  and  information 
technology.  Consequently,  DoD 
finds  itself  behind  the  curve  in 
software,  leading  to  upward- 
spiraling  information  technology 
(IT)  costs,  obsolescent 
systems,  and  the  loss  of  agility 
for  commanders  on  the  ground. 

In  the  private  sector,  changes  in 
design  methodologies  for 
software  development  are 
enabling  enormous  gains  in 
productivity  and  efficiency. 

Individuals  and  companies  are 
able  to  leverage  open 
technology  platforms  to  rapidly 
deploy  new  solutions  and 
capabilities  to  improve  their 
competitive  advantage.  These 
open  technology  platforms  may 
be  open  source  or  proprietary 
software  applications  with  open 
standards  and  published 
interfaces  that  allow  the  rapid 
development  of  new  capabilities 
by  third  parties  without 
coordination  agreements. 


DOD  needs  to  leverage 
the  corporate  mindset 
that  goes  along  with  the 
shift  to  OTD. 


Fundamentally, 
companies  have  realized 
that  technology  is  now  a 
commodity  and  the 
business  model  is 
providing  professional 
services  for  solutions 
versus  closed  products. 

IBM  provides  a  good 
example  of  engineering  a 
corporate  culture  change 
away  from  proprietary 
implementations  to 
leveraging  and  heavily 
investing  in  open 
solutions. 
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US  National  Interest 

DoD  has  two  competing  interests: 

1)  Provide  for  the  defense  of  the  US 

2)  Support  and  grow  the  US  industrial  base,  which  provides 
materiel  and  systems  so  that  DoD  can  accomplish  its  mission. 

These  trade-offs  are  well  understood  for  physical  goods  and 
services,  but  not  as  well  understood  for  digital  ones.  DoD  can  easily 
calculate  the  cost  difference  between  developing  or  acquiring  a 
physical  good  or  service  by  simply  comparing  make  or  buy  costs. 
There  is  however  a  fundamental  difference  between  physical  and 
digital  products.  Digital  goods  (software  code,  music,  movies,  etc.) 
once  created  can  be  copied  perfectly  with  relative  ease:  limiting 
distribution  enforces  scarcity,  but  that  scarcity  is  arbitrary  and 
negotiated,  rather  than  an  innate  property  of  the  product.  Software’s 
replicability  also  means  it  can  be  incorporated  into  other  software 
systems  without  “using  up”  the  original  component,  as  one  would 
with  physical  components. 

The  business  model  of  purchasing  physical  goods  and  services  has 
served  DoD  well  in  the  past;  but  it  falls  short  when  applied  to 
software  acquisition.  By  treating  DoD-developed  software  code  as  a 
physical  good,  DoD  is  limiting  and  restricting  the  ability  of  the 
market  to  compete  for  the  provision  of  new  and  innovative  solutions 
and  capabilities.  By  enabling  industry  to  leverage  an  open  code 
development  model,  DoD  would  provide  the  market  incentives  to 
increase  the  agility  and  competitiveness  of  the  industrial  base. 

Currently  within  DoD,  there  is  no  internal  distribution  policy  or 
mechanism  for  DoD  developed  and  paid  for  software  code.  By  not 
enabling  internal  distribution,  DoD  creates  an  arbitrary  scarcity  of  its 
own  software  code,  which  increases  the  development  and 
maintenance  costs  of  information  technology  across  the 
Department.  Other  negative  consequences  include  lock-in  to 
obsolete  proprietary  technologies,  the  inability  to  extend  existing 
capabilities  in  months  vs.  years,  and  snarls  of  interoperability  that 
stem  from  the  opacity  and  stove-piping  of  information  systems. 

DoD  needs  to  evaluate  the  impact  that  locking  into  one  set  of 
proprietary  standards  or  products  may  have  to  its  ability  to  react 
and  respond  to  adversaries  and  more  importantly,  to  technological 
change  that  is  accelerating  regardless  of  military  conflict.  In  order  to 
remain  competitive  in  a  rapidly  shifting  technological  landscape 
(including  the  disruptive  technologies  leveraged  by  our 
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adversaries),  DOD’s  software  development  and  business  processes 
must  break  out  of  the  industrial-era  acquisitions  mold. 

If  DoD  charts  a  course  to  increase  the  use  of  open  source  software 
AND  create  an  internal  DoD  collaborative  code  repository  the 
effects  would  be  transformative. 

US  National  Security 

Software  code  has  become  central  to  the  warfighter’s  ability  to 
conduct  missions.  If  this  shift  is  going  to  be  an  advantage,  rather 
than  an  Achilles’  heel,  DoD  must  pursue  an  active  strategy  to 
manage  its  software  knowledge  base  and  foster  an  internal  culture 
of  open  interfaces,  modularity  and  reuse.  This  entails  a  parallel  shift 
in  acquisitions  methodologies  and  business  process  to  facilitate 
discovery  and  re-use  of  software  code  across  DoD. 

The  national  security  implications  of  open  technology  development 
are  clear:  increased  technological  agility  for  warfighters,  more 
robust  and  competitive  options  for  program  managers,  and  higher 
levels  of  accountability  in  the  defense  industrial  base.  DoD  needs  to 
use  open  technology  design  and  development  methodologies  to 
increase  the  speed  at  which  military  systems  are  delivered  to  the 
warfighter,  and  accelerate  the  development  of  new,  adaptive 
capabilities  that  leverage  DoD’s  massive  investments  in  software 
infrastructure. 

To  summarize:  open  source  software  and  open  source 
development  methodologies  are  important  to  the  National  Security 
and  National  Interest  of  the  United  States  for  the  following  reasons: 

>  Enhances  agility  of  information  technology  industries  to 
more  rapidly  adapt  and  change  to  user  needed  capabilities. 

>  Strengthens  the  industrial  base  by  not  protecting  industry 
from  competition.  Makes  industry  more  likely  to  compete  on 
ideas  and  execution  versus  product  lock-in. 

>  Adoption  recognizes  a  change  in  our  position  with  regard  to 
balance  of  trade1  of  information  technology. 


1  China  is  striving  to  become  a  leader  in  open  source 
(http://www.linuxinsider.com/story/32421  .html, 

http  ://business.  newsforqe.com/article.  pl?sid=05/1 1/04/1 727259&tid=1 10) 
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>  Enables  DoD  to  secure  the  infrastructure  and  increase 
security  by  understanding  what  is  actually  in  the  source 
code  of  software  installed  in  DoD  networks. 

>  Rapidly  respond  to  adversary  actions  as  well  as  rapid 
changes  in  the  technology  industrial  base. 


This  roadmap  outlines  a  plan  to  implement  Open  Technology 
Development  (OTD)  practices,  policies  and  procedures  within  the 
Department  of  Defense. 

Open  Technology  Development 

There  is  one  thing  stronger  than  all  the  armies  in  the  world,  and  that 
is  an  idea  whose  time  has  come. 

-  Victor  Hugo 

Software  code  has  become  central  to  how  the  war-fighter  is  able  to 
conduct  missions.  If  this  shift  is  to  be  a  strength,  rather  than  an 
Achilles’  heel,  DoD  must  pursue  an  active  strategy  to  manage  its 
software  knowledge  base  and  foster  an  internal  culture  of  open 
interfaces,  modularity  and  reuse.  This  entails  a  parallel  shift  in 
acquisitions  methodologies  and  corporate  attitude  to  facilitate 
discovery  and  re-use  of  software  code  across  DoD. 


Open  Technology  Development  combines  salient 
advances  in  the  following  areas: 

1.  Open  Standards  and  Interfaces 

2.  Open  Source  Software  and  Designs 

3.  Collaborative/Distributive  culture  and  the 
and  online  support  tools 

4.  Technological  Agility 


Open  technology  development  (OTD)  methodologies  rely  on  the 
access  ability  of  a  software  community  of  interest  or  practice  to 
accessible  access  software  code  or  application  interfaces  that 
enable  decentralized  development  of  capabilities  that  leverage  the 
existing  code  base.  OTD  methodologies  have  been  used  for  open 
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source  software  development,  open  standards  architectures,  and 
the  most  recent  generation  of  web-based  collaborative 
technologies. 

OTD  includes  open  source  software  (OSS)  initiatives  (e.g.  Linux, 
Apache),  but  is  not  limited  to  open-source  software  development 
and  licensing  regimes  (e.g.  GPL),  which  enforce  unlimited 
redistribution  of  code.  It  is  important,  in  the  context  of  this  report 
and  resulting  policy  discussions,  to  distinguish  between  OSS  and 
OTD,  since  the  latter  may  include  code  whose  distribution  may  be 
limited  to  DoD,  and  indeed  may  only  be  accessible  on  classified 
networks.  Nor  does  the  promotion  of  OTD  within  DoD  impinge  on 
the  legal  status  of  software  developed  by  with  private  sector  money 
by  commercial  vendors. 

Rather,  the  hinge  issues  are: 

•  How  can  DoD  leverage  military-funded  software 
development  more  effectively? 

•  How  can  OTD’s  business-process  advantages  increase  both 
the  rate  of  innovation  and  the  sustainability  of  software 
developed  on  DoD’s  dime? 

•  What  changes  in  acquisition  practice  and  policy  may  be 
required  to  capture  the  benefit  of  OTD  within  and  across  the 
Defense  Department? 

•  How  can  DoD  leverage  existing  external  OSS  resources? 

Building  on  previous  Open  Source  Software  studies,  experiments, 
projects,  and  initiatives,  this  report  recommends  shifts  in  the 
process  of  technology  acquisition  from  closed,  locked-in  black  box 
systems  to  open  and  modular  approaches.  These  open  approaches 
are  based  on  open  standards,  services  based  architectures,  open 
source  collaboration  and  reference  open  source  implementations. 
These  shifts,  in  turn,  enable  a  business  process  migration  from 
proprietary  products  that  can  only  be  changed  by  one  vendor, 
towards  a  marketplace  for  professional  services  to  extend  and 
adapt  capabilities  on  demand. 

This  roadmap  charts  actionable  tasks  and  phases  to  introduce  this 
change  into  DoD  acquisition  and  technology  development  over  the 
next  two  years,  in  a  way  that  immediately  and  aggressively  expands 
DoD’s  technological  agility  and  the  ability  of  program  managers  to 
enforce  accountability  in  software  development  funded  by  the 
military. 
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Objective:  Adapt  the  current  technology  acquisitions  process 
to  default  to  Open  Technology  Development  implementations. 

The  objective  of  this  project  is  to  facilitate  the  transition  to  Open 
Technology  Development  practices.  The  recommended  approach  is 
to  modify  the  current  system  and  processes  so  that  OTD  practices 
become  default  behavior  for  DoD  technology  acquisitions  programs. 


The  current  environment  encourages  total  control 
versus  sharing  and  risk  taking. 

Key  to  this  transition  will  be  a  rewards  system  for 
encouraging  the  leveraging  of  external  solutions, 
taking  intelligent  risk  for  substantial  gains,  and 
factoring  in  life  cycle  costs  and  advantages  that  can 
be  passed  to  other  projects. 


These  new  approaches  contrast  sharply  with  traditional 
requirements-based  development  and  procurement  programs  that 
do  not  leverage  software  development  efforts  across  DoD,  either  by 
using  existing  DoD  software  or  engineering  software  that  can  be 
leveraged  from  outside  of  the  system  in  question.  Currently,  there  is 
little  incentive  for  a  program  manager  to  find  this  leverage,  for  a 
variety  of  reasons: 

•  Discovery:  DoD-developed  software  that  would  be  relevant 
to  a  program  is  impossible  to  find  because  no-  one  knows 
what’s  been  developed  outside  their  purview. 

•  Contractual  IP  Silos:  Contracts  are  written  so  that  it  is 
difficult  to  access  source  code  in  another  program  (even  by 
the  program  manager  responsible),  much  share  that  source 
code  across  programs 

•  Incentives:  Even  if  they  could  access  source  code  across 
DoD,  program  managers  currently  have  little  or  no  incentive 
to  do  so.  The  current  culture  encourages  and  rewards 
based  on  budget  and  organizational  size.  In  this 
environment  saving  time  by  re-using  software  would  reduce 
their  budgets  (and  thus  their  prestige)  and  entail 
collaboration  with  a  software  community  of  practice,  rather 
than  status  as  sole  master  of  their  program  domain. 
Similarly,  there  are  few  incentives  for  a  program  manager  to 
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publish  or  disseminate  code  developed  by  his  program, 
because  doing  so  does  not  generate  funding  to  sustain  that 
software. 

Incremental  changes  in  requirements,  policies,  procedures  and 
reviews  are  necessary  to  establish  Open  Technology 
Development  as  default  behavior  in  the  acquisitions  and 
development  process. 


Figure  1  Overall  OTD  transition  approach 


Approach 

Key  to  the  transition  will  be  the  dissemination  of  OTD  as  a 
transformative  business  process  that  increases  technological  agility, 
expands  the  range  of  competitive  options  for  program  managers, 
and  fosters  accountability  in  the  defense  industrial  base. 

Implementation  of  OTD  can  be  phased  as  follows: 

•  Near  term  -  Demonstrate  on  AS&C  Projects 

•  Mid  term  -  OTD  requirements  and  process  in  FY07  AS&C 
project  selection 

•  Long  term  -  transition  practices  to  external  agencies 


10 


The  plan  will  target  the  following  areas: 

1 .  Leverage  open  source  infrastructure  and  technologies 

2.  Apply  open  source  collaborative  technologies  to  smaller 
communities 

3.  Change  the  default  acquisitions  and  development  behavior  to 
default  to  technology  services  vs.  products 

Ultimately,  the  government  will  need  to  embrace  Open 
Technologies  Development,  integrate  it  into  formal  acquisition 
directives  and  policies  and  enforce  it’s  application  through 
appropriate  procedures  and  review  processes., . 

Recommendations 

This  roadmap  effort  proposes  a  transition  to  Open  Technology 
Development  practices  in  the  Department  of  Defense,  initially 
focusing  on  the  projects  and  activities  within  AS&C.  Success  is 
defined  as  a  programmatic  environment  in  which  policies, 
procedures,  requirements  and  practices  establish  DoD  source  code 
access,  open  interfaces  and  systems,  and  collaborative 
development  methodologies  as  the  default  baseline  for  technology 
development  and  business  process.  Once  established  within  AS&C, 
those  processes  can  be  spread  to  larger  programs  and  acquisitions 
using  the  metrics  and  information  gathered  along  the  way. 
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A  multi-prong  approach  is  recommended  for  FY06. 


Open  Technology  Studies,  Coordination,  and  Policy 

Development 


Formalize  and  embed 


Figure  2  Projects  and  practices  within  AS&C  will  provide  the 
near  term  focus  for  the  OTD  transition  activities 

The  roadmap  planning  team  recommends  the  following  steps  to 
accomplish  these  objectives: 

•  Create  an  Evolutionary  Planning  activity  to  oversee  and 
guide  transition  efforts  and  establish  a  government  lead 

•  Create  an  AS&C  Advisory  Board  to  review  Open  Technology 
Development  material,  provide  advice  and  activities 

•  Establish  formal  relationships  with  external  programs  and 
communities  promoting  this  approach 

•  Initially  focus  on  AS&C  projects,  create  leveragable  software 
assets  and  gather  metrics. 

•  Network  and  communicate  these  efforts  externally 

•  Establish  review  gates,  policies  and  processes  to  reinforce 
the  new  behavior 

As  with  any  transition,  the  ultimate  goal  is  to  institutionalize  the 
changes.  The  critical  path  for  OTD  is  to  demonstrate  benefits,  build 
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advocacy,  and  modify  the  existing  system  with  new  OTD 
requirements,  processes  and  reviews.  These  changes  should  be 
positioned  as  ways  to  drive  agility,  accountability  and  risk  mitigation 
into  design  processes  and  program  management,  in  anticipation  of 
the  quicker  delivery  of  a  more  cost  effective,  better  performing 
product.  An  important  element  of  accountability  in  this  context  is  to 
consider  long  term  operational,  maintenance  and  lifecycle  costs,  not 
only  for  the  current  project,  but  also  for  the  software  acquisitions 
and  development  process  at  large. 
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1.  Introduction  &  Background 


This  report  provides  a  roadmap  for  the  meaningful  introduction  of 
open  source  software,  open  standards,  and  advanced  collaborative 
technology  development  into  the  Department  of  Defense.  The 
mission,  projects,  and  resources  of  AS&C  provide  a  logical  starting 
point  for  these  transitional  activities.  This  roadmap  focuses  on  near 
term  actions  activities  that  can  be  coordinated  and  managed 
through  the  AS&C  with  the  goal  of  transitioning  these  activities  into 
the  larger  acquisition,  information  technology,  and  operational 
structure  of  the  Department  of  Defense. 

Recently,  Ken  Kreig  (Under  Secretary  of  Defense  for  Acquisition, 
Technology  and  Logistics)  stated  that  in  2015  the  projected  number 
of  lines  of  code  required  for  avionics  compared  to  software  coders 
will  be  overwhelming2.  The  dilemma  is  clear:  if  there  are  not  going 
to  be  enough  engineers  to  design,  build  and  test  software  with 
current  methodologies,  new  methodologies  must  evolve  to  better 
leverage  the  distributed  population  of  engineers  and  scientists 
developing  DoD  warfighting  systems  and  IT  infrastructure. 

What  is  Open  Technology  Development? 

Open  Technology  Development  refers  to  a  number  of  practices  for 
development  and  implementation  of  current  and  next-generation 
software.  These  changes  and  paradigm  shifts  are  enabled  by  the 
Internet  and  related  technologies,  which  enable  distributed  groups 
of  programmers  to  collaboratively  develop  and  manage  code 
libraries  in  a  decentralized  fashion. 

The  key  elements  of  this  approach  are: 

1.  Open  Standards  and  Interfaces 

2.  Open  Source  Software  and  Designs 

3.  Collaborative  and  distributed  online  tools 

4.  Technological  Agility 


2  Conversation  with  Sue  Payton,  DUSD  -  AS&C 
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Open  standards  and  interfaces  were  initially  established  through 
ARPA  and  distributed  via  open  source  software  reference 
implementations.  User  to  user  messaging  evolved  into  user-to-user 
chats,  email,  and  social  software  such  as  weblogs,  wikis  and  user¬ 
generated  data  tagging.  Distributed  communities  of  interest  were 
able  to  form  and  evolve  in  response  to  technical  gaps  and  pain 
points.  The  resulting  set  of  tools  and  conventions  for  agile  software 
development  have  evolved,  coalescing  over  the  last  ten  years  into 
robust  and  well-documented  methodologies. 


Open  Standards  and  Interfaces 

As  software  becomes  increasingly  networked,  design  and 
engineering  methodologies  have  evolved  towards  services-based 
architectures  that  communicate  through  open  and  standardized 
interfaces.  Often,  these  services  and  interfaces  are  provided  with 
open  source  software  reference  implementations.  Once  this  type  of 
open,  service-based  architecture  is  implemented,  the  system 
naturally  decomposes  into  a  modular  design  -  each  service  is  free 
to  improve  and  evolve  independently  as  long  as  it  communicates 
through  the  standard  interfaces. 

In  this  context,  any  given  software  service  may  be  COTS,  GOTS,3 
or  open  source  -  the  best  implementation  can  be  chosen,  evolved 
and  replaced  if  a  better  technological  option  is  available.  Properly 
implemented,  open  standards  and  solutions  create  a  level  playing 
field  that  allows  the  underlying  technologies  to  evolve  while 
minimizing  interface  complexity.  In  addition,  the  modularity  afforded 
by  open  standards  and  interfaces  radically  reduce  technological  risk 
by  eliminating  cascading  software  dependencies,  and  reduce 
financial  risk  by  eliminating  the  need  to  re-engineer  or  re-integrate 
the  system  when  new  capabilities  or  requirements  are  introduced. 


3  COTS  -  Commercial  off-the-shelf,  GOTS  -  Government  off-the-shelf 
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Srriif'f** 

Figure  3  Services  based  architecture  with  open  standards 

•  Reduces  Technological/Financial  Risk  and  Lock-In 

•  Component  Services  can  Improve  and  Compete  over  Time 

•  Enables  New  Technology  Insertion  Without  System  Re- 
Engineering  or  Re-Integration 

In  order  to  reap  these  benefits,  DoD  programs  must  replace  closed 
systems  and  proprietary  API’s  with  open  standards  and  interfaces. 
Open  Source  reference  implementations  of  these  interfaces  and 
services  validate  implementation  details;  provide  basic  functionality 
and  a  starting  point  for  more  evolved  implementations. 
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Open  Source  Software  and  Designs 

There  are  over  100,000  publicly  available  open  source  projects 
available  spanning  most  functional  areas.4  Many  of  these  projects 
provide  mature  and  robust  solutions  in  their  areas  of  focus.  When 
possible,  open  source  software  components  should  be  leveraged 
rather  than  funding  the  development  of  equivalent  proprietary 
components  for  specific  programs. 

Initial  opportunities  for  open  source  software  use  include 
Information  Technology  infrastructure,  communications 
technologies,  as  well  as  advanced  geospatial  infrastructure. 
Information  exchange,  geospatial  awareness,  and  advanced 
collaborative  services,  which  are  common  requirements  of  many 


4  http://sourceforqe.net 
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modern  Department  of  Defense  systems.  Existing  open  source 
solutions  typically  promote  and  comply  with  published  interface 
standards,  providing  systems  interoperability.  Given  the  resources 
being  externally  applied  in  these  areas,  programs  should  follow, 
adopt,  and  leverage  these  solutions,  cognizant  of  open-source 
licensing  requirements. 

Rather  than  subsidizing  the  rewriting  of  existing  private-sector  code, 
government  resources  and  funding  should  be  focused  on  areas 
where  external  investment  is  not  being  made,  areas  where  military 
requirements  are  not  being  addressed,  and  classified  technologies. 
Within  these  areas  smaller  communities  of  interest  should  be 
encouraged  to  use  the  same  tools  and  processes  that  have  proven 
successful  in  external  open  source  development.  The  government 
has  legal  and  valid  military  reasons  to  encourage  or  require  open 
technology  development  within  those  communities  of  interest, 
allowing  specific  systems  and  technologies  to  evolve  more  quickly 
in  response  to  emerging  threats  and  capabilities. 

Collaborative  Tools  and  Technologies 

Most  open  source  software  projects  nurture  communities  of  interest 
whose  members  have  vastly  different  skills  and  backgrounds  and 
may  never  have  met  face  to  face.  Consequently,  a  number  of  tools 
have  evolved  to  enable  efficient  network-based  communication, 
configuration  management,  error  tracking,  and  online  collaboration. 

In  many  cases,  the  tools  and  distributed  nature  of  the  collaboration 
serve  to  refine  and  distill  communications,  and  to  drive  communities 
towards  the  best  technological  solution  for  a  given  problem. 

Because  these  communities  share  both  resources  and 
technological  needs,  the  competitive  and  evolutionary  nature  of 
these  collaborations  quickly  leads  to  standardization  on  the  best-of- 
breed  tools  for  a  given  function.  When  something  better  comes 
along,  it  doesn't  take  very  long  for  that  capability  to  disseminate 
between  various  projects. 
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A  current  snapshot  of  some  of  these  tools  and  functions  would 
include: 

•  Mailing  lists 

•  Internet  relay  chat  rooms 

•  Wiki 5  web  sites  for  communications 

•  Bugzilla  6  for  discrepancy  reporting  and  tracking 

•  CVS7  or  Subversion8  for  source  code  configuration  management 

•  Doxyaen9  for  source  code  documentation 

•  RSS19  feed  for  notification 

•  gcc  tools11  for  software  development 

•  Collabnet  and  others  are  offering  on-line  tools  for  overall  project 
and  program  management 

This  genre  of  tools  and  technologies  should  be  deployed  within 
Department  of  Defense  software  development  community  to  drive 
OTD.  Indeed,  “the  medium  is  the  message”  in  this  regard,  since 
open  source  development  is  inextricable  from  the  collaborative  tools 
used  to  facilitate  it.  Without  affordances  for  distributed  collaboration 
between  programmers  and  the  formation  of  decentralized  software 
communities  of  interest,  OTD  is  not  feasible. 


Because  the  pace  of  evolution  of  these  tools  is  rapid,  it  would  be 
counter-productive  to  lock  in  particular  implementations.  DoD 
development  teams  need  the  flexibility  to  follow  and  implement  the 
"best  of  breed"  of  these  tools  and  services.  Similarly,  it  would  be 
folly  (and  a  contradiction  of  OTD’s  underlying  logic)  if  DoD  insisted 
on  the  engineering  of  a  top-down  code  management  system  or 
collaborative  tool  suite  specifically  for  military  use,  rather  than 
leveraging  existing,  mature  and  well-documented  COTS  capabilities 
designed  specifically  for  the  development  and  stewardship  of 
source  code  by  distributed  communities  of  interest  (including  large 
enterprises  which  use  COTS  for  this  purpose).  Current  system 
administration  policies  and  practices  of  government  and  contractor 


5  http://www.mediawiki.org/wiki/MediaWiki 

6  http://www.bugzilla.org/ 

7  http://www.nongnu.org/cvs/ 

8  http://svnbook.red-bean.com/ 

9  http://www.stack.nl/~dimitri/doxygen/ 

10  http://www.xml.eom/pub/a/2002/12/18/dive-into-xml.html 

11  http://www.gnu.0rg/s0ftware/s0ftware.html#TOCDescripti0nsOfGNUS0ftware 
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organizations  will  need  to  be  modified  to  allow  the  installation  and 
operations  of  these  tool  sets. 


Technological  Agility  should  be  a  metric 
-  Col  John  Boyd 

The  pace  of  technological  innovation  continues  to  accelerate  as 
new  tools  and  practices  continue  to  evolve.  The  government  should 
avoid  standardizing  and  requiring  specific  operating  systems  and 
applications  and  encourage  the  continuing  refresh  and  applications 
of  the  latest  approaches.  To  maintain  a  technological  lead,  it  will  be 
increasingly  important  to  provide  the  flexibility  to  adopt  new 
solutions  and  services  as  they  are  developed  externally. 

Appropriate  review  and  validation  of  various  technologies  will  be 
incorporated  into  the  plan.  Specialized  or  critical  areas  such  as  real 
time  code,  guidance  systems,  and  cryptographic  processing  areas 
will  require  more  stringent  testing  than  generic  information 
technologies  that  are  in  wide  use.  Contractors  that  deliver  solutions 
will  need  to  test  and  validate  their  deliverables  in  all  cases. 

Continued  emphasis  on  spiral  and  evolutionary  programmatics  will 
be  required.  The  current  pace  of  external  technological 
advancement  needs  to  be  factored  into  our  programs.  Large 
hierarchical  management  and  design  teams  need  to  be  re-factored 
into  more  autonomous  design  teams  that  communicate  through 
collaborative  tools. 

Information  Gathering 

Open  Technology  Design  practices  are  expanding  in  many  areas  of 
commercial  and  government  business.  To  assist  AS&C  in  its 
adoption  of  these  practices  the  team  has  begun  to  gather  relevant 
information  and  make  contact  with  some  of  these  efforts. 

Information  gathering  will  be  an  ongoing  component  of  the  OTD 
transition  plan  so  that  we  may  apply  existing  resources  and  lessons 
learned  to  our  efforts. 


Historical  Background 

Government  Research  and  Development  is  best  applied  to  evolving 
technology  and  science  in  areas  where  commercial  businesses 
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cases  have  not  yet  formed.  In  these  areas,  it  is  often  the  case  that  a 
commercial  return  on  investment  argument  is  difficult,  even  when 
the  desired  capability  would  be  in  the  national  interest.  To  support 
these  initiatives  the  Department  of  Defense  has  evolved  advanced 
projects  through  DARPA  followed  by  cost  plus  contracts  with 
requirements  based  development  through  the  acquisitions  system. 
Cost  plus  contracts  mitigate  the  risk  and  establish  a  workable 
business  model  for  government  contractors  to  pursue  national 
objectives  while  developing  unique  and  complex  systems. 

This  structure  has  evolved  and  created  its  own  culture  and 
processes  within  the  Department  of  Defense  and  its  associated 
contractors.  When  this  system  was  originally  created,  the 
government  generated  the  vast  majority  of  research  and 
development  funding.  The  government  was  able  to  guide  and 
control  these  technologies  due  to  this  control.  Today,  there  are  still 
many  cases  where  this  funding,  leadership,  and  control  remain  with 
the  Department  of  Defense.  Examples  include  advanced  aircraft, 
ships,  tanks,  and  weapons  systems. 

In  many  other  areas  the  technological  leadership  is  now  external  to 
the  Department  of  Defense.  Business  models  have  evolved  to 
support  higher  levels  of  research  and  development  funding  as  well 
as  new  development  practices.  In  the  case  of  computer  and 
information  technology  the  innovation  is  primarily  coming  from 
outside  of  the  government.  Often,  the  government  lags  in  adopting 
these  technologies  and  practices.  The  current  DoD  requirements 
process  and  approval  process  is  slower  than  the  rate  of 
technological  advances  in  these  industries.  In  many  functional 
areas  it  can  be  argued  that  technology  is  now  a  “commodity”  - 
especially  areas  where  robust  open  source  solutions  exist. 
Commodities  should  be  acquired  in  an  open  market  using 
commercial  practices.  Technological  development  and  integration 
on  these  commodity  open  source  technologies  should  be  treated  as 
a  professional  service  -  not  a  product. 

Some  of  the  more  innovative  DoD  projects  have  involved  small 
teams  working  outside  of  the  standard  acquisition  and  development 
practices.  Government  decision  makers  have  recognized  this  in 
recent  years.  The  845  contracting  mechanism  employed  within  the 
NGA  National  Technical  Alliance,  DARPA  challenges,  and  other 
DoD  programs  are  just  a  few  of  the  mechanisms  that  are  attempting 
to  address  this  growing  gap  between  internal  and  external 
technologies.  A  number  of  agencies  are  currently  looking  into  ways 
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to  speed  up  decision  and  contracting  cycles  to  close  the  gap  with 
commercial  cycles. 

The  pace  of  technological  change  continues  to  accelerate  and  more 
technology  is  being  developed  externally.  Additionally,  Internet 
based  collaborative  technologies  and  distributed  development  tools 
have  created  a  paradigm  shift  with  open  source  software  and  open 
standards.  At  a  minimum,  these  advances  need  to  be  effectively 
leveraged  and  applied  in  government  activities.  Given  that  these 
same  advances  are  openly  available  and  can  be  accessed 
internationally  -  it  becomes  strategically  important  that  our  existing 
acquisition  practices  do  not  put  us  at  a  disadvantage.  Agility  of 
capabilities  deployment  needs  to  become  the  mantra  for  the  DoD 
acquisitions  community. 

Fortunately,  there  are  prior  examples  where  agility  of  technology 
development  was  a  virtue  not  a  vice.  In  the  book  Skunkworks,  by 
Ben  Rich  and  Leo  Janos,  they  describe  the  process  of  how 
Lockheed's  advanced  airplane  design  division,  Skunkworks,  rapidly 
assembled  some  of  the  planes  they  are  known  for: 

"We  [...]  were  able  to  keep  costs  down  by  incorporating  the  flight 
controls  of  the  General  Dynamics  F-16  fighter  and  using  the 
engine  from  the  McDonnell  Douglas  F-1 8.  We  didn't  start  from 
scratch  but  adapted  off-the-shelf  avionics  developed  by  others" 

Parts  and  pieces  were  scavenged  off  of  existing  platforms;  this 
lowered  the  risks  that  a  major  technology  project  would  not  fail  due 
to  a  new  flight  controller  or  engine.  This  is  the  essence  of  open 
technology  development:  using  and  improving  what  is  already 
present,  so  that  new  time  and  energy  can  be  spent  on  future 
technology  challenges,  not  building  existing  systems. 

Currently  within  DoD  acquisitions  programs  software  code  is  reused 
on  a  limited  basis.  For  example,  within  an  individual  DoD  program 
office,  software  code  from  a  previous  contractor  may  be  shared  with 
a  new  contractor  taking  their  place.  But  as  rule,  sharing  of  code 
across  the  DoD  enterprise  does  not  occur.  As  a  result  the  possibility 
that  development  funding  is  wasted  by  multiple  efforts  is  high. 
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Champions  and  How  They  View  OTD 


CIO’s  who  don't  come  to  term  with  this  [open  source]  revolution 
in  2003  will  be  paying  too  much  for  IT  in  2004 
CIO  Magazine  12 

Champions  -  Public  &  Private  Sector 

•  US  Federal  Government,  Component  Organization  and 
Registration  Environment  (CORE),  13 

CORE.GOV  provides  a  collaboration  environment  for  component 
development,  registration  and  reuse.  CORE.gov  began  operation  in 
March  2004.  Over  time,  it  will  become  a  networked  community  of 
component  developers  and  users  and  will  offer  numerous 
components  of  various  types  and  complexities,  including  business 
components,  e-forms  and  technical  components. 

CORE.GOV  grew  out  of  the  Federal  Enterprise  Architecture  (FEA) 
Project  Management  Office,  the  goal  of  which  is  to  support  cross¬ 
agency  collaboration,  transformation  and  government-wide 
improvement.  CORE.GOV  offers  an  environment  where  component 
developers  and  users  collaborate  seamlessly  and  easily. 

•  IBM  14 

In  a  word,  open  source  is  collaboration.  More  specifically,  it's  public 
collaboration  on  a  software  project.  IBM  has  committed  to  open 
source  in  a  big  way  with  contributions  to  more  than  120  projects, 
including  more  than  $1  billion  in  Linux  development.  According  to 
the  Open  Source  Initiative  (OSI),  it  can  be  defined  this  way:  "Open 
source  promotes  software  reliability  and  quality  by  supporting 
independent  peer  review  and  rapid  evolution  of  source  code.  To  be 
OSI  certified,  the  software  must  be  distributed  under  a  license  that 
guarantees  the  right  to  read,  redistribute,  modify,  and  use  the 
software  freely." 


12  http://www.cio.com/archive/031503/opensource.html 

13  http://core.gov/ 

14  http://www-128.ibm.com/developerworks/opensource/ 
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The  community  source  approach  at  IBM  is  a  means  to  an  end.  We 
believe  in  an  Internet  connected  world  with  the  business 
requirements  that  the  on-demand  era  of  information  technology  is 
suggesting.  There  is  going  to  be  an  important  shift  and  to  deliver 
technology  that  addresses  that  shift  in  both  customer  requirements 
as  well  as  our  technological  capacity,  we  have  decided  to 
systematically  componentize  and  modularize  our  software.  That  is 
allowing  us  to  get  to  the  market  much  more  quickly  to  address 
these  requirements  in  a  much  more  time  and  cost  effective  manner. 

So  with  that  recognition  that  this  is  the  way  we  are  going  to  develop 
software  going  forward  it  is  clear  to  us  that  the  way  we  traditionally 
develop  applications  is  sub-optimal  to  achieve  this  goal.  It's  a  very 
ambitious  goal;  no  one  has  tried  to  do  it  on  the  scale  and  scope  that 
we  are  doing  it. 

We  very  much  believe  that  the  software  industry  is  moving  through 
the  same  kind  of  componentization  transition  that  many  other 
industries  ranging  from  the  automotive  industry  to  the  disk  drive 
industry  and  chip  industry  have  all  gone  through.  And  the 
companies  that  emerge  from  this  transition  and  have  successfully 
broken  their  products  down  into  sub-assemblies  to  reusable 
components  will  have  tremendous  advantage  in  the  marketplace. 

So  that's  the  driving  motivator.  Community  Source  is  a  way  to  get 
there. 


•  CSC 15 

The  lure  of  open  source  software  is  that  it  is  free — anyone  can  use 
it  or  modify  it  without  license  fees,  and  no  vendor  can  lock  users  in 
for  fixes  and  enhancements.  Open  source  has  spawned  a 
worldwide  development  community  that  improves  and  fixes  the 
software,  often  much  faster  than  in  the  proprietary  vendor  world. 
The  disruptive  nature  of  open  source  software  makes  it  the  focus  of 
the  2004  CSC  Leading  Edge  Forum  report,  Open  Source:  Open  for 
Business. 


15  http://www.csc.com/features/2004/48.shtml 
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•  HP  16 

HP  has  over  200  products  that  ship  with  open  source  software.  HP 
hosts  over  50  open  source  projects  on  SourceForge,  the  online 
open  source  repository. 

•  Apple 17 

Apple's  open  source  projects  allow  developers  to  customize  and 
enhance  key  Apple  software.  Through  the  open  source  model, 

Apple  engineers  and  the  open  source  community  collaborate  to 
create  better,  faster  and  more  reliable  products  for  our  users. 

As  the  first  major  computer  company  to  make  Open  Source 
development  a  key  part  of  its  ongoing  software  strategy,  Apple 
remains  committed  to  the  Open  Source  development  model.  Major 
components  of  Mac  OS  X,  including  the  UNIX-based  core,  are 
made  available  under  Apple’s  Open  Source  license,  allowing 
developers  and  students  to  view  source  code,  learn  from  it  and 
submit  suggestions  and  modifications.  In  addition,  Apple  uses 
software  created  by  the  Open  Source  community,  such  as  the 
HTML  rendering  engine  for  Safari,  and  returns  its  enhancements  to 
the  community. 

Apple  believes  that  using  Open  Source  methodology  makes  Mac 
OS  X  a  more  robust,  secure  operating  system,  as  its  core 
components  have  been  subjected  to  the  crucible  of  peer  review  for 
decades.  Any  problems  found  with  this  software  can  be  immediately 
identified  and  fixed  by  Apple  and  the  Open  Source  community. 

•  Google 18 

Chris  DiBona,  Google's  open  source  program  manager,  said, 
"Google  is  promoting,  supporting  and  using  open-source  software." 
Google  currently  supports  open  source  software  such  as  Jabber, 
GoogleMaps  and  uses  open  API’s  to  Google’s  platform.19 


16  http://opensource.hp.com/ 

17  http://developer.apple.com/darwin/ 

18  http://www.eweek.com/article2/0,1 895,1 877924, OO.asp 

19  http://code.google.com/ 
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•  Merrill  Lynch 

Merrill  Lynch  sees  software  as  an  enabler  of  their  competitive 
advantage.  They  have  over  4,000  developers  working  on  open 
source  technology..  Merrill  is  both  actively  contributing  to  the  public 
open  source  code  base  as  well  as  reusing  specific  Merrill-enterprise 
software  code. 

•  Sun  Microsystems 

Sun  has  already  released  most  of  Solaris  as  open  source,  and  is 
now  promising  to  release  the  Java  Enterprise  System,  N1  System 
Manager,  Identity  Management  Suite,  SunRay  server  software, 
developer  tools,  and  more. 20  They  are  also  planning  to  fully 
integrate  all  of  this  software  into  the  Solaris  OS,  to  provide  an 
integrated  stack  called  the  Solaris  Enterprise  System.  The  Sun 
Java  Enterprise  System  and  developer  tools  are  also  available  for 
other  platforms,  including  Linux,  HP-UX,  and  Windows. 

Scott  McNealy  Founder  and  CEO,  Sun  Microsystems  -  “You  learn 
to  share  in  preschool.  Later  you  learn  that  if  you  make  the  pie 
bigger,  everyone  gets  a  little  more.  These  lessons  came  together 
when  we  started  Sun.  We  didn't  have  the  resources  to  do 
everything  ourselves,  so  we  shared  what  we  had  to  attract 
customers  and  get  their  help  in  building  the  business.  There  are 
now  4.5  million  Java  developers  and  about  950  companies 
worldwide  all  collaborating  on  a  technology  Sun  shared  with  the 
community. 

This  is  possible  because  sharing  creates  communities,  which  create 
new  markets.  It's  also  changing  business  models:  Companies  can 
no  longer  expect  to  lock  in  customers  with  proprietary  standards. 
They  must  now  compete  on  the  value  of  their  business  execution. 
They  monetize  that  value  a  little  bit,  spread  over  the  entire 
community.  With  1  billion  people  on  the  network  today,  and  several 
million  more  joining  every  week,  there's  a  lot  of  opportunity.  So 
while  it  may  seem  counterintuitive  for  a  company  to  share,  it's  the 


20  http://trends.newsforge.eom/trends/05/1 2/01/1 422245.shtml?tid=1 38 
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key  to  larger  economic  growth  -  not  only  for  Sun,  but  also  for 
everyone  in  the  world.” 

Benefits 

Open  Source  Software  development  and  integration  emphasizes  a 
spiral  development  approach.  Software  baselines  are  periodically 
tested  and  released.  Internally,  most  projects  are  managed  in  a 
hierarchical  and  modular  structure.  Systems  integration  ties  the 
various  capabilities  together  through  open  standards,  linking  to 
project  functionality,  or  wholesale  integration  of  working  source 
code  into  other  projects.  In  other  words,  OSS  does  not  imply 
laissez-faire  project  control  -  there  are  management  controls, 
deadlines,  etc.  in  OSS  development  just  as  there  are  in  any  other 
product  delivery  activity. 

The  "Open  Source  Model"  is  a  very  practical  way  of  evolving 
technology  in  a  rapidly  changing  environment.  The  supporting 
collaborative  tools  that  have  enabled  open  source  development 
harnesses  the  collective  wisdom,  experiences  and  requirements  of 
its  most  demanding  users  to  ensure  that  needs  are  rapidly  met.  In 
recent  years  this  model  has  rapidly  transitioned  from  a  small  group 
of  technical  early  adopters  to  widespread  deployment  in  the 
corporate  world.  Open  source  software  technology  stacks  now  form 
the  basis  of  the  bulk  of  Internet  and  information  sharing 
technologies. 

The  latest  innovative  advances  in  languages,  services  based 
architectures,  and  standards  based  approaches  have  their  roots  in 
open  source  projects.  Most  successful  open  source  software 
projects  have  the  same  features  as  proprietary  software: 21 

•  Commercially  available  technical  support 

•  Training  classes 

•  Managed  Release  Schedules  at  reasonable  intervals 

•  Binary  distributions  for  popular  platforms 

•  Active  User's  Groups  exchanging  experiences 


21  http://www.theaceorb.com/product/benefit.html 
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A  summary  of  some  additional  advantages  offered  by  open  source 
software: 

Encourages  software  re-use 

Open  source  software  development  allows  programmers  to 
cooperate  freely  with  other  programmers  across  time  and  distance 
with  a  minimum  of  legal  friction.  As  a  result,  open  source  software 
development  encourages  software  re-use.  Rather  than  endlessly 
reinventing  wheels,  a  programmer  can  just  copy  someone  else's 
elegant  tire  from  another  machine. 

Can  increase  code  quality  and  security 

With  closed  source  software,  it's  often  difficult  to  evaluate  the 
quality  and  security  of  the  code.  In  addition,  closed  source  software 
companies  have  an  incentive  to  delay  announcing  security  flaws  or 
bugs  in  their  product.  Often  this  means  that  their  customers  don't 
learn  of  security  flaws  until  weeks  or  months  after  the  security 
exploit  was  known  internally. 

Open  source  software  is  potentially  subject  to  scrutiny  by 
many  eyeballs 

Therefore  bugs,  security  flaws,  and  poor  design  cannot  hide  for 
long,  at  least  when  the  software  has  a  community  of  programmers 
to  support  it.  And  since  fixing  the  code  doesn't  depend  on  a  single 
vendor,  patches  are  often  distributed  much  more  rapidly  than 
patches  to  closed  source  software. 

Decreases  vendor  lock-in 

Businesses  no  longer  have  to  be  locked-in  to  the  whims  of  a 
sole-source  vendor.  No  more  paying  a  vendor  for  a  needless 
upgrade,  simply  to  maintain  compatibility  with  others  using  the 
same  software.  Business  data  is  also  more  "future-proof",  since 
most  open  source  programs  save  text  files  in  ANSI  standard  ASCII 
files,  instead  of  proprietary  binary  formats.  If  the  vendors  training 
materials  are  inadequate,  because  they  have  access  to  the  source 
code,  external  vendors  can  supply  as  good  or  better  manuals.  Most 
successful  open  source  software  programs  have  extensive  online 
FAQ's,  manuals,  and  mailing  lists. 

Reduces  cost  of  acquisition 

Most  open  source  software  is  available  for  a  nominal  cost,  often 
the  price  of  the  media,  or  the  time  of  the  download.  No  more  "per- 
seat"  license  fees.  Reduced  acquisition  cost  means  that  start-ups 
don't  have  to  part  with  precious  capital  when  they  need  it  most. 
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Established  companies  can  try  the  software  with  minimal  risks.  If 
the  company  wants  to  develop  a  piece  of  software  that  they  don't 
plan  to  use  to  differentiate  them,  they  can  reduce  the  cost  by 
collaborating  with  several  companies  on  the  same  code  base.  If  you 
want  to  incorporate  the  code  into  your  product,  you  don't  have  to 
pay  a  license  fee. 

Increases  customizability 

Every  organization  has  unique  needs  or  desires.  Linux  has  been 
ported  to  everything  from  embedded  microcontrollers,  to  IBM 
mainframes.  If  there's  a  nagging  bug  you  want  fixed,  you  can  hire 
someone  else  to  fix  it.  If  two  programs  don't  play  well  together,  one 
or  both  can  be  modified  to  eliminate  the  incompatibility. 

Meritocratic  community 

A  true  meritocracy,  in  the  open  source  community,  a 
programmer's  status  and  fame  depends  on  programming  skill. 

Open  source  expertise  travels  well,  and  you  can  reuse  software  you 
developed  for  one  company  at  future  employers.  When  one 
government  agency  develops  or  modifies  a  technology,  that  benefit 
is  available  to  other  government  agencies  by  default  unless 
restricted  by  security  processes. 22 


22  http://www.openknowledge.org/writing/open-source/scb/why-open-source.html 
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"If  I  have  seen  further  it  is  by  standing  on  the  shoulders  of 
Giants. "  -  Isaac  Newton 

The  scientific  process  has  become  one  of  the  most  successful 
areas  of  human  endeavor  due  to  its  openness,  the  free  exchange  of 
ideas  and  the  steady  accumulation  of  knowledge  available  to  all.  It 
has  overtaken  all  competing  methods  of  analyzing  the  world  around 
us,  by  showing  that  it  can  consistently  deliver  better  results.  The 
status  achieved  by  science  took  a  long  time  to  arise,  and  even 
though  we  find  its  power  now  utterly  compelling,  this  wasn't  always 
obvious  to  everyone  throughout  much  of  history. 

The  open  source  development  process  will  eventually  become  the 
most  successful  due  to  its  advantages  of  openness  and  the  free 
exchange  of  ideas,  and  the  steady  accumulation  of  program  source 
code  available  to  all.  The  open  source  development  method  will 
overtake  competing  software  development  methods  to  achieve  this 
status  by  consistently  delivering  better  results.  While  we  now 
glimpse  the  compelling  nature  of  this  promise,  this  has  not  always 
been  the  case  throughout  much  of  the  Information  Technology 
industry's  history.  23 


23  http://www.cyber.com.au/users/conz/shoulders.html 
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2.  Roadmap  Activities 


The  Open  Technology  Development  roadmap  activities  were 
accomplished  from  October  to  December  of  2005.  The  team 
employed  the  same  collaborative  tools  and  practices  that  are  used 
in  online  development  to  coordinate  and  prepare  this  report.  Many 
studies  and  initiatives24  have  been  previously  accomplished  in  this 
area.  As  in  a  typical  open  source  software  project,  the  study  has 
attempted  to  reuse  and  leverage  much  of  that  work.  A  Wiki  (online 
collaborative  space)  was  employed  for  communication  and 
collaboration;  online  publishing  resources  were  used  for  the  final 
report. 

Goals 

The  practices,  tools,  and  resources  employed  by  open  source 
software  projects  and  solutions  have  consistently  outperformed 
traditional  closed  source  methodologies.  These  practices  are  also 
being  applied  to  hardware  design  and  collaboration  between 
communities  of  interest. 

Ultimately,  there  are  three  defined  goals: 


1 .  Leverage  open  source  infrastructure  and 
technologies 

2.  Apply  open  source  collaborative  technologies 

3.  Change  the  default  acquisitions  and  development 
behavior  to  default  to  technology  services  vs. 
products 


Success  occurs  when  these  methodologies  are  applied  by  default  in 
the  development  of  technology  within  the  DoD.  The  transition 
includes  multiple  tasks  and  sub-goals  in  near,  mid,  and  long  term 
phases. 

Creating  an  index  that  would  allow  DoD  to  discover  source  code  is 
key  to  this  project.  Initially  the  index  would  be  person  -entered  lists 
of  types  of  software  projects,:  later  more  advanced  and  automatic- 
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indexing  services  could  be  deployed.  These  needs  have  already 
been  addressed  with  the  proliferation  of  open  source  projects; 
repositories,  indexes,  and  rating  systems  have  been  developed  and 
deployed  as  open  source  solutions. 


AS&C  Role  in  Open  Technology  Development 

AT&L  and  AS&C  specifically,  has  already  played  a  central  role  in 
changing  how  technology  is  developed  and  deployed  for  the 
military.  Open  technology  development  would  continue  that  trend  by 
enabling  DoD  as  an  enterprise  to  be  more  agile  and  innovative 
delivering  solutions  to  the  warfighter  at  an  increased  rate. 

AS&C  can  create  and  lead  the  community  of  interest  by  fostering 
and  investing  in  methods  leading  to  the  adoption  of  open 
technology  methods.  Key  areas  need  to  be  researched  for  DoD  in 
the  policy  (contracts  and  acquisitions)  and  legal  (such  as  copyright 
and  software  distribution)  arenas.  Investments  also  need  to  be 
made  in  basic  enterprise  collaboration  infrastructure,  such  as 
websites,  etc.  AS&C  can  be  the  organizing  node  for  DoD  OTD  and 
develop  the  standards  for  new  communities  to  index,  search  and 
discover  new  software  code. 

The  ACTD  program  could  also  promote  the  use  of  OTD  by  forcing 
contractors  to  use  open  source  software  and  promulgate  those 
changes  (where  applicable)  back  into  the  private  sector  or  DoD 
enterprise.  ACTD  could  also  pay  for  code  delivery,  support,  and 
integration. 


Senior  Leadership  Role 

For  OTD  to  flourish,  AS&C  will  need  to  provide  top  level  cover  for 
these  bottom-up  efforts.  It  is  recommended  that  the  senior 
leadership  focus  on  internal  and  external  communications 
supporting  the  OTD  benefits  and  transition.  The  planning  staff 
should  assist  with  the  drafting  of  letters,  policy  statements,  news 
stories  that  talk  about  both  the  need  and  implementation  for  the 
OTD  transition. 
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In  roadmap  meetings,  DUSD  AS&C  Ms  Sue  Payton  outlined  the 
following  talking  points  that  she  intends  to  focus  on  in  the  near  term: 

1.  Increased  military  jointness 

2.  Manufacturing  needs  to  be  at  lower  costs 

3.  OSS  software  process  provides  better  producibility 

Clear  and  periodic  communication  with  OSD  oversight  personnel, 
program  managers,  contractors,  and  other  senior  OSD  staff  will  be 
key  in  assisting  this  transformation.  Reinforcement  through  formal 
communications,  policies,  processes,  and  advisory  teams  will  help 
to  embed  this  behavior  into  the  system. 

The  OTD  transition  is  consistent  with  external  initiatives  in  other 
areas  of  DoD  and  should  be  linked  with  those  efforts  when  possible: 

•  SecDef  is  being  briefed  every  month  about  how  we  can 
shrink  the  force  (by  lowering  workload  because  OSS  may 
help  reduce  the  workload  and  yield  other  benefits.  The 
SecDef  should  be  briefed  on  these  benefits). 

•  2002  defense  bill  -  entitlements  are  $4  billion  in  2009  it  will 
be  $20  billion.  Need  to  do  more  with  less 

•  Defense  Business  Transformation  Efforts 

•  Initiatives  emphasizing  networking  vs.  hierarchical  control 
structures 

•  Disruptive  technology  evaluations 

A  component  of  the  leadership  role  for  AS&C  is  to  develop  DoD 
sponsors  and  dedicate  internal  human  resources  for  coordination 
and  transition  of  the  OTD  effort  within  OSD.  An  OTD  point  person 
within  AS&C  would  enable  the  OTD  effort  to  more  successfully 
navigate  OSD  policy,  legal  and  acquisitions  structures  as  well  as 
facilitating  the  deployment  of  these  methodologies  within  programs 
and  projects.  This  position  could  be  either  an  IPA  or  a  federal 
government  employee.  It  is  important  for  AS&C  to  designate  this 
position  as  a  means  of  maintaining  persistent  focus  on  the  OTD 
agenda  and  deflecting  industry-sponsored  efforts  that  could  dilute 
or  change  the  vision. 

Finally,  the  continuing  support  of  the  DUSD  AS&C  in  periodic  OTD 
status  and  planning  meetings  will  be  key  to  the  success  of  the 
transition. 
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Challenges 
Culture  and  Process 

The  primary  challenges  to  this  transition  will  be  cultural,  not 
technical.  Over  time,  government  acquisitions  and  development 
processes  have  built  a  bureaucracy  and  rewards  system  that 
encourages  and  supports  the  status  quo.  Careers  are  advanced 
primarily  on  program  size,  not  necessarily  overall  efficiency. 
Furthermore,  government  contractors  are  measured  by  revenue; 
government  program  managers  are  measured  by  the  size  of  their 
organization  and  their  overall  budget.  The  canonical  government 
contracting  process  creates  high  entry  costs  for  small  innovative 
companies  -  the  established  contractors  attempt  to  control  their 
positions  through  proprietary  implementations  and  interfaces.  The 
system  is  very  good  at  protecting  itself  -  new  approaches,  such  as 
OTD,  will  have  to  endure  legal,  security,  and  process  challenges. 
The  current  infrastructure  will  attempt  to  delay  change,  claim  they 
are  adapting  by  trying  to  assume  control  of  the  innovative  process. 

To  accomplish  this  transition,  outside  resources,  contractors,  and 
practices  need  to  be  brought  in.  The  system  and  current  processes 
will  need  to  be  incrementally  modified  to  impose  new  requirements, 
processes,  metrics,  and  reviews.  In  the  end,  budgets  and  contracts 
will  drive  the  change  as  new  business  models  are  implemented. 

The  challenge  is  to  change  the  environment  and  the  current  system 
defaults.  In  this  regard,  the  system  and  bureaucracy  is  our  friend 
and  it  will  be  necessary  to  sell  “Accountability”  as  the  driver  for  the 
changes.  It  is  hard  to  argue  against  accountability. 

Program  managers  and  leaders  need  to  take  ownership  of  the  life 
cycle  costs  of  their  solutions.  Metrics  and  reviews  will  need  to  be 
imposed  that  highlights  this  accountability.  Credit  and  rewards 
should  be  provided  when  those  solutions  are  leveraged.  The  OTD 
process  has  to  ensure  that  the  Program  manager  is  properly 
supported  as  OTD  projects  are  measured  against  the  current 
system.  Recognition  and  rewards  need  to  be  established  for 
Program  managers  that  deliver  open  solutions. 


There  are  a  number  of  technical  and  process  changes  that  will  be 
required  -  again  these  are  not  technical  issues,  but  cultural  ones. 
The  collaborative  tools,  databases,  discrepancy  reporting, 
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configuration  management,  and  testing  tools  exist  and  work  well  in 
the  unclassified  network  environment.  Experts  and  supporters  of 
the  external  projects  are  in  the  best  position  to  introduce  the  rapid 
spiral  and  collaborative  teamwork  practices.  Support  and  education 
of  these  new  practices  to  government  contractors  will  occur,  as  the 
functionality  is  integrated  and  applied  to  government  use. 


Typically  Requirements  driven,  planned  not 
evolutionary,  little  evolution  or  change  during 
implementation  cycle 
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Requirements  Driven 

Must  comply  with  constantly  outdated  specs 
Must  synchronize,  control,  coordinate  all 
resources  and  interfaces 
Competition  and  closed  by  default 


Figure  4  Hierarchical  structures  of  traditional  programs 

In  the  extreme,  traditional  government  acquisitions  are  managed  on 
fairly  long  timelines  beginning  with  requirements  definition  followed 
by  resource  allocation  and  scheduling  and  then  implementation. 
These  processes  and  structures  typically  don't  respond  well  to 
change  once  the  waterfall  schedules  have  been  generated  and 
reviewed.  Tasks  are  decomposed  into  sub-tasks  and  programmers 
are  assigned  to  implement.  Programmers  are  forced  to  live  within 
their  sub-task  boxes  -  Program  Managers  keep  everyone  focused 
on  their  assigned  area.  New  functionality  is  discouraged  in  this 
process.  It  requires  a  new  validated  requirement  and  an 
engineering  change  request  before  implementation. 
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Rapid  Cycles,  Evolutionary,  Decisions  made  frequently  by  implemented  and  users 
Opportunistic  and  evolutionary,  quickly  combine  and  head  to  new  goals 
Reuse  and  collaboration  by  default 


Figure  5  Goal  driven  collaborative  projects,  with  internal 

hierarchies 

Open  source  projects  are  goal  driven  and  very  opportunistic. 
Contrary  to  popular  belief,  they  are  often  hierarchically  managed 
with  defined  areas  of  responsibility  assigned  to  module  leads. 
Implementations  can  quickly  change  direction  to  take  advantage  of 
other  open  source  code  that  is  discovered.  Innovation  and 
communication  is  rewarded  with  increased  recognition  and 
responsibility.  Standardization  of  interfaces  allows  decisions  to  be 
made  by  the  implementers.  Automation,  efficient  communication, 
and  access  to  the  latest  tools  is  expected  and  required  in  this 
environment. 
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Obviously,  there  will  be  a  number  of  challenges  in  integrating  these 
two  approaches.  Some  of  those  challenges  are: 

•  Velocity  of  Change 

•  Requirements  based  vs.  Goal  driven  Spiral  Development 

•  IT  culture  -  transition  from  meetings  to  groupware 

•  Adoption  of  OTD  practices  that  are  emerging  in  academia 
and  the  commercial  world 

•  Industrial  Base  business  plan 

•  Lack  of  Open  Source  Skill  Set  in  Government 

•  Metrics  for  evaluating  open  source  software  products 

Software  Project  Governance 

As  mentioned  previously,  traditional  software  development  projects 
are  managed  in  a  top-down  hierarchical  fashion.  Open  technology 
development  projects  instead  rely  on  different  models  of 
governance  to  decide  the  direction  of  software  code.  Some  of  the 
better  know  software  projects  have  the  following  governance 
structures25: 

1 .  Benevolent  Dictator(s).  In  the  case  of  the  development  of 
Linux,  Linus  Torvalds  makes  the  final  decision  with  respect 
to  direction  of  the  code,  but  has  lieutenants  who  have 
responsibility  over  various  pieces  of  software  code. 
Lieutenants  organize  the  various  people  who  wish  to  play  a 
part,  accepting  and  modifying  code  as  it  submitted. 

2.  Exclusive  Group:  the  Apache  Webserver  group  is  comprised 
of  about  a  dozen  people.  Only  these  people  are  allowed  to 
make  changes  to  the  releasable  version  of  the  code. 
Suggestions  are  submitted,  but  the  core  group  are  the  only 
ones  who  make  and  release  changes  in  the  code. 

It  should  also  be  noted  that  no  individual  within  these 
communities  is  being  directly  paid  by  the  code-group  for  their 
involvement  with  the  community.  Each  person  volunteers 
his/her  time  to  work  on  the  software  code,  some  individuals  may 
have  support  as  part  of  their  job  responsibilities  with  an 
employer  while  others  work  these  projects  on  their  own  time. 

Community  governance  is  a  key  issue  to  developing  the  OTD 
model  within  DoD.  The  OTD  team  needs  to  develop  a 
governance  model  that  will  enable  the  users,  developers  and 


25  The  Success  of  Open  Source,  Steven  Weber 
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funders  of  the  development  to  feel  that  their  contribution  matters 
and  is  needed  by  the  community. 

Software  Policy  and  Licensing 

There  is  a  clear  distinction  between  using  open  source  code 
developed  in  the  private  sector  and  fostering  an  OTD  development 
methodology  within  DoD.  A  distinction  has  been  made  for  use  of 
open  source  software  by  both  the  White  House  (Federal 
Government  Policy  on  the  use  of  open  source  software26)  and  the 
DoD  CIO  (Open  Source  Software  in  the  Department  of  Defense27); 
both  state  that  open  source  software  can  be  treated  like  proprietary 
software  as  long  as  the  software  meets  DoD  requirements 
(acquisitions  rules,  security,  etc.). 

What  is  less  clear,  however,  is  how  the  US  Government  deals  with 
distribution  of  software  code  it  has  paid  for  or  how  federal 
government  employees  deal  with  copyright,  since  current  OSS 
licensing  uses  copyright  as  its  foundation.  Legal  and  contract  issues 
may  arise  when  contractors  and  federal  workers  modify  and 
distribute  code  into  the  public  domain.  Also,  for  government 
contractors  there  is  a  desire  to  negotiate  away  any  rights  the 
government  has  to  distribute  new  code,  either  internal  to  the  DoD 
enterprise  or  into  the  private  sector.  Current  literature28  defines 
several  significant  areas  with  IP  law,  created  versus  purchased 
software,  services  and  contracts  that  need  to  be  evaluated  and 
policies  created  before  a  large  scale  DoD  wide  OTD  rollout. 

There  currently  isn’t  any  DoD  mandated  policy  on  how  to  deal  with 
copyrighting  of  software  created,  or  modified  by  government 
employees,  since  copyright  is  automatically  granted  to  the  creator 
of  the  software  work.  There  are  a  few  groups  within  DoD  who  have 
begun  researching  the  legal  issues  (Dept  of  the  Navy  CIO)  around 
open  technology  development,  but  these  groups  have  access  to 
only  limited  funding  which  will  slow  the  adoption  of  OTD  methods  by 
DoD. 


26Federal  Government  Policy  on  the  use  of  open  source  software,  OMB 
Memorandum  M-04-16,  SUBJECT:  Software  Acquisition, 
http://www.whitehouse.gov/omb/memoranda/fy04/m04-16.html 

27  Open  Source  Software  (OSS)  in  the  Department  of  Defense  (DoD),  May  28, 
2003,  DOD  CIO  Memo 

28  Licensing  Software  and  Technology  to  the  U.S.  Government,  M.S.  Simchak, 
D.A.  Vogel,  CCH  Incorporated,  IL,  2000 
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It  is  important  to  note  that  many  of  the  legal  and  IP  issues 
surrounding  Open  Source  Software  in  the  private  sector  do  not 
necessarily  apply  to  software  which  is  developed  exclusively  for 
DoD  use  and  not  released  outside  of  DoD;  IP  issues  for  this 
software  can  be  navigated  within  the  FAR  by  well-informed 
contracting  officers  and  program  managers  (the  level  of  contracting 
savvy  within  DoD  is  another  issue).  In  order  to  reduce  contracting 
officers’  and  program  managers’  FUD  (Fear  Uncertainty  &  Doubt) 
factor  regarding  OTD  and  increase  the  level  of  leverage  in 
negotiations  with  vendors,  one  concrete  step  towards  clarifying  the 
legal  status  of  OTD  within  DoD  is  the  creation  of  an  Open 
Technology  Development  License  by  DoD  through  the  general 
counsel’s  office.  This  license  would  clarify  that  the  software 
developed  under  OTDL  will  become  source  accessible  across  DoD 
and/or  the  federal  government  (for  software  likely  to  be  used  by 
multiple  federal  agencies,  the  latter  may  be  desirable).  Such  a 
license  would  clarify  the  distinction  between  DoD  or  government 
rights  to  the  source  code  and  commercial  rights  to  the  software, 
which  may  be  retained  by  developers,  as  they  already  are  under  the 
FAR. 

A  DoD/USG  Open  Technology  License  is  a  tool  that  would  greatly 
facilitate  the  adoption  and  dissemination  of  OTD  practices  in  the 
face  of  cultural  resistance  from  vendors  and  business-as-usual 
program  managers.  It  would  require  resources  for  the  legal  time  to 
craft  such  a  license,  but  the  investment  would  reduce  friction  for 
OTD  as  it  scales. 


DoD  Acquisitions  Process 

Developing  a  robust  underlying  code  base  for  the  DoD  enterprise  is 
important.  Unfortunately,  the  current  DoD  acquisitions  process 
limits  the  ability  of  DoD  to  reuse  software  code  to  scale  solutions 
across  the  enterprise.  Instead,  contracts  and  DoD  rules  encourage 
individual  offices  to  not  share  code.  The  end  result  is  that  DoD 
software  cannot  be  rapidly  changed  to  meet  new  missions  and  DoD 
becomes  less  agile  as  an  enterprise. 
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OSD  AT&L  has  created  the  Defense  Acquisitions  Performance 

Assessment  (DAPA)  Report29  to  review  acquisitions  capability 

delivery  to  the  warfighter. 

Relevant  recommendations  for  OTD  include: 

Strategic  technology  exploitation  is  a  key  factor  that  allows 
the  U.S.  to  maintain  dominant  military  capabilities.  Militarily 
critical  technologies  need  to  be  identified  and  documented 
early  in  the  acquisition  process  to  ensure  that  cutting  edge 
technologies  have  appropriate  export  controls. 

The  fundamental  nature  of  defense  acquisition  and  the 
defense  industry  has  changed  substantially  and  irreversibly 
over  the  past  20  years.  New  and  emerging  global  markets 
have  substantially  affected  the  dynamics  of  acquisition 
reforms  envisaged  in  the  Goldwater-Nichols  Act.  In  1985, 
defense  programs  were  conducted  in  a  robust  market 
environment  where  more  than  20  fully  competent  prime 
contractors  competed  for  multiple  new  programs  each  year. 
The  industrial  base  was  supported  by  huge  annual 
production  runs  of  aircraft  (585),  combat  vehicles  (2,031), 
ships  (24)  and  missiles  (32,714).  In  1985,  threats  were  well- 
known  and  well-defined.  This  allowed  the  Department  to 
conduct  stable  strategic  planning.  Today,  the  Department 
relies  on  six  prime  contractors  who  compete  for  fewer  and 
fewer  programs  each  year.  Reductions  in  plant  capacity 
have  failed  to  keep  pace  with  the  reduction  in  demand  for 
defense  systems  (188  aircraft,  1 90  combat  vehicles,  8  ships, 
5,072  missiles).  The  security  environment  has  become 
unpredictable,  threats  are  often  difficult  to  define  and 
situations  often  require  asymmetric  responses.  The  world 
dynamic  has  changed. 

The  Department  must  be  agile  -  to  an  unprecedented 
degree  --  to  respond  quickly  to  urgent  operational  needs 
from  across  the  entire  spectrum  of  potential  conflicts. 

The  Department  compounds  the  chaotic  nature  of  its 
financial  model  with  a  program  oversight  philosophy  based 
on  lack  of  trust.  Effective  oversight  has  been  diluted  in  a 


29  http://www.dapaproiect.org,  January  2006 
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system  where  the  quantity  of  reviews  has  replaced  quality, 
and  the  tortuous  review  processes  have  obliterated  clean 
lines  of  responsibility,  authority  and  accountability. 

Complex  acquisition  processes  do  not  promote  program 
success  --  they  increase  costs,  add  to  schedule  and 
obfuscate  accountability. 


Implementation  Plan 

The  roadmap  activity  has  created  a  forward  action  plan  for 
beginning  OTD  transition  efforts  in  2006.  The  approach  is  shown  in 
the  following  diagram: 


Open  Technology 
Development 


Studies,  Coordination,  and  Policy 


Formalize  and  embed 


Figure  6  Functional  activities  for  FY06 

Each  of  the  functional  areas  is  covered  in  more  detail  in  the 
following  pages. 
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1.  Planning  and  Networking 

The  OTD  team  augmented  with  additional  technical  support  will 
continue  to  coordinate,  plan,  and  gather  information  to  support  the 
transition.  These  activities  will  be  funded  through  the  Large  Data 
JCTD,  as  this  is  one  of  the  first  projects  that  intend  to  implement 
these  practices.  The  main  function  of  the  core  OTD  team  will  be  to 
oversee  and  assist  efforts  in  the  OTD  Implementation  Plan: 

•  Near  term  -  Demonstrate  OTD  with  AS&C  Projects 

•  Mid  term  --  Address  OTD  requirements  and  review  in  AS&C 
Project  selection  process 

•  Long  term  —  Conduct  external  coordination  and 
collaboration 


2.  Demonstrations  and  Metrics 

To  accomplish  the  transition,  initial  emphasis  should  be  placed  on 
bringing  in  external  open  source  software  resources  and  projects  to 
demonstrate  the  methodology  and  educate  projects  on  these 
practices.  Where  possible,  existing  key  contributors  and  developers 
of  open  source  projects  should  be  subcontracted  for  the  technical 
implementation. 

Demonstration 
ACTD  and  JCTDs 

•  Educate  and  Evangelize 

•  Target  Specific  Activities  for  implementation* 

•  Carrot  &  Stick  approach 

•  Communities  of  Interest  that  have  no  formal  support  (GIS, 
Modeling  &  Simulation) 

•  Identify  Leaders  and  Champions 

Coalition  Activities 

Coalition  activities  should  be  a  key  area  to  focus  for  the  adoption  of 
Open  Technology  Development  activities.  Historically,  technology 
development  between  coalition  partners  has  been  a  goal  that  has 
proven  difficult  to  achieve.  Good  ideas  and  projects  are  often 
bogged  down  in  import/export  or  intellectual  property  issues.  In 
some  cases,  a  solution  is  imposed  on  participating  members,  thus 
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denying  the  benefits  that  might  be  achieved  through  collaborative 
development. 

Open  Technology  Development  in  general  and  open  source 
software  in  particular  provides  a  logical  mechanism  to  demonstrate 
international  technology  collaboration.  Starting  with  information 
technology  and  information  exchange,  there  are  many  open  source 
projects  that  could  be  quickly  applied  to  meet  mission  requirements. 
Since  the  underlying  technologies  are  already  being  developed 
online  with  international  communities  of  interest,  many  of  the 
historical  problems  do  not  exist  with  this  approach. 

Recommendation:  Evaluate  the  potential  use  of  the  Defense 
Challenge  Program  (DCP)  to  demonstrate  Open  Technology 
alternatives  to  projects  or  programs  that  have  implementation 
issues;  e.g.,  make  application  of  open  source  based  products  or 
development  methodologies  a  specific  interest  item  for  DCP. 


Metrics 

DoD  must  work  to  increase  transparency  of  software  in  programs 
(costs,  reuse,  etc.),  and  enforce  modularity  in  programmatics:  one 
proprietary  element  cannot  be  allowed  to  zero  the  reuse  value  of  an 
entire  system  developed  on  DoD’s  budget. 

Shifting  Program  Evaluation  &  Incentives 

•  Software  Architecture  is  Transparent  and  Modular 

System  is  Transparent:  Developed  and  managed  as  a  set 
of  self-contained  or  loosely  coupled  functional  components. 

If  components  interact,  there  is  an  explicit  and  non¬ 
proprietary  set  of  inputs  and  outputs  for  each  functional 
component 

System  is  Adaptable:  Functional  components  can  be 
updated  or  replaced  without  ripple  effects  to  the  system  as  a 
whole,  as  long  as  new  components  address  non-proprietary 
input  and  output  requirements. 

Modularity  is  important  not  just  because  it  increases  DoD's  agility, 
but  also  because  it  allows  open  technology  development  to 
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accommodate  proprietary  software  applications  without 
compromising  this  agility.  There  are  a  lot  of  great  proprietary 
applications  in  the  DoD  software  space,  and  there's  nothing  wrong 
with  using  them.  But  DoD  cannot  allow  one  proprietary  software 
element  to  compromise  the  sustainability  and  leveragability  of  its 
investment  in  an  entire  IT  system.  Modularity  ensures  that 
proprietary  elements  can  be  part  of  the  IT  ecosystem  without 
contaminating  the  source-use  of  DoD-funded  systems. 

•  Lock-in  Quotient 

To  what  degree  is  the  program  "locked  in"  to  a  proprietary  software 
application?  The  development  of  quantitative  metrics  for  lock-in 
quotient,  from  completely  modular  and  open  to  "if  we  want  to  make 
a  change,  we  have  to  deal  with  vendor  X  or  else  start  over"  would 
force  the  evaluation  of  both  technical  architecture  and 
contracting/legal  agreements.  Differential  flow  of  money  to  less 
locked-in  projects  would  heighten  program  managers'  awareness  of 
these  issues,  which  they  might  not  have  heeded  before,  i.e.  they  let 
their  contracting  officers  take  care  of  the  paperwork,  and  the 
paperwork  puts  DoD  in  a  straightjacket  with  regard  to  IP  and  re-use. 

Lock-in  metrics  also  allow  DoD  to  avoid  an  untenable  "all  or 
nothing"  policy  position  about  open  technology  development. 

Rather  than  declaring  that  all  DoD  IT  development  will  be  open  by  a 
certain  date,  the  lock-in  quotient  for  programs  funded  by  AS&C  (or 
other  DoD  agencies)  can  be  ratcheted  down  over  a  period  of  time, 
which  gives  the  industrial  base  both  a  competitive  incentive  and 
time  to  adjust. 

•  Leverage  Quotient: 

What  proportion  of  a  proposed  system  leverages  existing  GOTS 
or  open  source  software  components?  Leverage  quotient  is  a 
measure  of  software  development  efficiency  -  leveraging  use  of 
existing  software  rather  than  re-inventing  the  wheel.  Leverage 
should  be  positively  rewarded  and  viewed  as  an  innovation 
driver,  not  just  a  cost  savings  mechanism.  The  question  is,  if  a 
contractor  could  find  GOTS  components  for  x%  of  the  system, 
what  would  it  do  to  build  new  or  better  capabilities  with  the 
money  it  otherwise  would  have  spent  rewriting  code? 

Leverage  quotient  metrics,  like  lock-in  metrics,  can  be  ratcheted 
towards  open  technology  development  over  time.  The  goal  is  to 
create  a  rewarding  niche  for  high  leverage  technology 
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proposals,  while  preserving  a  niche  for  projects  that  are  lower- 
leverage  because  they  are  truly  cutting  edge. 

*  Multiplier  Metrics: 

For  ongoing  DoD  programs,  a  Multiplier  Metric  is  the  flip  side  of 
the  above  Leverage  Quotient  -  how  many  times  have  software 
components  of  a  program  been  leveraged  by  other  programs  or 
projects?  If  a  program  ABC  spends  $1 M  on  a  given  software 
capability,  and  that  capability  is  used  by  four  other  systems  that 
otherwise  would  have  re-developed  the  same  capability,  then 
program  ABC  has  a  4x  multiplier  on  investment  for  that  software 
component. 

This  metric,  combined  with  money  incentives,  provides 
incentives  for  PM's  to  not  only  share,  but  to  evangelize  re-use  of 
their  systems,  which  drives  participation  in  software  repositories 
and  information  sharing  vs.  hoarding.  We  must  remember  that  a 
lot  of  the  behaviors  we  want  to  encourage,  i.e.  promoting 
awareness  of  existing  software  and  facilitating  code  transfer 
across  services,  are  largely  voluntary  behaviors  and  must  be 
worthwhile  for  the  individual  program  manager.  We  have  to 
answer  the  "what's  in  it  for  me"  question.  If  a  program  manager 
can  demonstrate  that  he  is  a  force  multiplier  in  DoD  software 
development,  his  IT  budget  should  reflect  that  DoD  gets  a 
disproportionate  bang  for  its  buck  from  this  program. 

Conversely,  program  managers  who  see  that  the  other  guy  is 
getting  more  money  because  his  software  is  getting  more  reuse 
will  be  forced  to  consider  the  possibility  that  they  might  be 
missing  out  because  no-one  knows  how  much  better  their  code 
is  than  that  other  guy's,  and  then  do  something  about  it.  In  a 
zero  sum  federal  budget  game,  the  threat  of  lost  resources  is 
often  a  more  powerful  incentive  than  the  hope  of  new 
resources.  In  the  current  system,  fear  of  lost  resources  drives 
people  to  secrecy  and  hoarding.  The  role  of  policy  (and  shifts  in 
funding)  is  to  tilt  the  game  so  that  fear  drives  people  to  open 
development  methodologies  and  networked  communities  of 
interest. 

3.  Resources  and  Support 

Resources  and  support  will  be  required  to  move  forward  with  this 

transition.  Much  good  work  has  been  previously  accomplished  with 

regards  to  policy,  evaluation,  and  development  of  relevant 
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technologies.  Where  possible  we  will  want  to  leverage  these  assets 
towards  the  end  objective.  OTD  transition  activities  should  include 
collaboration  with  national  labs,  academic  institutions  and 
supporting  government  agencies  that  are  already  engaged  in  OTD 
activities  in  a  variety  of  domains.  This  section  identifies  some  of 
those  resources  and  communities  of  interest,  which  should  be 
networked  and  leveraged  to  achieve  greater-than-sum-of-the-parts 
effects  in  transition  and  dissemination  of  OTD. 


Communities  of  Interest 


Figure  7  Communities  of  Interest  (COI)  for  OTD 


DoD  Organizations  and  Agencies:  A  number  of  DoD 
organizations  have  expressed  interest  in  being  a  part  of  the  OTD 
effort.  These  include: 

Defense  Business  Transformation  Agency  (BTA) 

This  new  DoD  organization  is  charged  with  coordinating/organizing 
business  systems  (human  resources,  accounting,  etc.)  spending 
across  DoD.  Overall  OSD  budget  for  this  Agency  is  $780  million; 
they  also  have  leverage  with  the  Services’  budget  of  $3.5  billion. 
BTA  would  be  a  good  partner  to  cultivate  as  they  are  new  (i.e.  not 
bureaucratically  sclerotic)  and  able  rapidly  to  set  and  create 
operating  standards. 


45 


Department  of  the  Navy  -  CIO  Office 

The  Navy  has  initiated  a  project  in  concert  with  the  National  Center 
for  Open  Source  Policy  and  Research  (NCOSPR),  to  examine  how 
to  apply  and  use  open  source  software  within  the  Navy.  The 
specifically  have  been  examining  the  legal  aspects  of  DoD 
developed  software  code,  contractors  and  government  employees. 
We  anticipate  being  an  active  part  in  this  effort  for  DUSD 
(AS&C)/OSD. 

Within  OSD,  informal  discussions  are  ongoing  with  the  Joint  Staff 
J6  and  OASD  (OSD/NII). 

National  Lab  Resources 

Several  supportive  external  resources  have  been  identified  during 
this  initial  study.  Formal  relationships  should  be  evaluated  and 
pursued  with  these  resources.  The  NCOSPR  is  unclassified  and 
has  experience  with  open  source  projects  and  methodologies.  The 
ILabs  has  adopted  open  source  software  infrastructure  and  has 
established  formal  interfaces  that  can  be  leveraged  on  classified 
networks.  These  resources  and  their  previous  work  can  be  used  to 
assist  in  the  transition  process. 

NCOSPR  (NASA  with  Stennis  and  WPAFB  MSRCs) 

As  a  National  Open  Source  Resource  Center,  NCOSPR's30 
mandate  is  to  serve  the  public  by  helping  to  identify  the  "common 
technical  needs"  within  government  agencies  and  bring  to  bear  the 
resources,  applications  and  expertise  of  the  IT  industry  and 
independent  open  source  development  communities  to  meet  these 
needs.  The  NCOSPR  provides  a  valuable  resource  for  coordinating 
external  open  source  projects  and  activities  against  AS&C  transition 
goals. 

Futures  Lab  (Aerospace/NRO) 

Aerospace  Corporation  is  an  FFRDC  primarily  supporting  the  Air 
Force,  NRO  and  the  Intelligence  Agencies.  Recently  they  have 
setup  an  experimental  lab  to  explore  various  technologies  that  sync 


30  http://www.ncospr.org/ 
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with  their  clients  missions.  The  lab  is  interested  and  available  to 
host  and  be  a  proponent  of  OTD. 


I  Labs  (NRO/NGA) 

The  ILabs  consists  of  several  classified  facilities  within  the 
intelligence  community.  Open  Technology  Development  practices 
are  being  advocated  and  supported  within  their  activities.  Significant 
computational  and  networking  resources  exist  to  support  classified 
networks  and  capabilities  within  the  labs.  Significant  groundwork  for 
access  to  live  operational  classified  data  has  been  accomplished 
through  collaboration  of  the  NRO  and  the  NGA.  The  labs  have 
recently  chosen  the  OSSIM  open  source  software  baseline  to 
demonstrate  the  advantages  of  an  open  systems  approach. 
Recommend  a  briefing  tour  be  established. 

The  OTD  effort  will  also  coordinate  and  recruit  the  following 
organizations  as  well  for  OTD: 

•  Intelligence  community  (CIA/NRO/NGA/NSA) 

•  NASA 

•  National  Counter  Terrorism  Center  (NCTC) 

•  Modeling  &  Simulation  Community 

•  Government  Accountability  Office 


Open  Source  Projects 

Geographic  Information  Systems  (GIS)  Community 

The  OTD  transition  plan  will  initially  focus  on  leveraging  existing 
open  source  software  capabilities  and  practices  into  AS&C  projects. 
An  advanced  open  source  geospatial  capability  is  one  of  the 
functional  areas  that  can  be  quickly  applied  in  addition  to  generic 
information  technology. 

The  GIS  community  has  already  embraced  open-source 
development  to  develop  highly  interoperable  systems.  Distributed 
organizations  have  already  been  set  up  in  the  form  of  OSSIM  (open 
source  software  image  map),  open  GIS  Consortium  and  Remote 
Sensing.  We  anticipate  cultivating  relationships  with  these  groups  to 
develop  case  studies  and  increase  their  visibility  within  DoD. 
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OSSIM 


The  Open  Source  Software  Image  Map  (OSSIM)31  project  has  been 
sponsored  and  applied  to  a  number  of  government  programs  over 
the  last  several  years.  Geospatial  awareness  is  a  desired  capability 
for  many  modern  projects.  This  project  support  national  and 
commercial  geospatial  formats  and  has  been  evaluated  in  previous 
government  studies.  Technical  support  with  advanced  security 
clearances  is  available  for  technical  assistance  allowing  the 
technology  to  be  quickly  applied  and  modified  to  the  needs  of  a 
specific  project. 


u  M 


Figure  8  Accurate  3D  Geo-spatial  view  from  OSSIM 


31  http://www.ossim.org/ 
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•  Open  Source  Geo-spatial  Foundation 

The  Open  Source  Geo-spatial  (OSGEO)  Foundation  32  has  become 
a  standard  for  online  mapping  interfaces.  Complying  with  OGC 
standards,  mapservers  and  underlying  open  source  software 
databases  can  quickly  be  implemented  to  provide  standardized 
online  collaborative  mapping  capabilities.  Several  commercial 
companies  have  focused  on  supplying  support  and  development 
services  for  these  projects. 

The  foundation  hosts  the  leading  open  source  geo-spatial  projects 
at  http://osqeo.org.  Founding  projects  include: 

•  GDAL 

•  GeoTools 

•  GRASS 

•  Mapbender 

•  MapBuilder 

•  MapGuide 

•  MapServer 

•  OSSIM 


32  http://mapserver.gis.umn.edu/ 
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Figure  9  MapServer  is  the  standard  for  web  based  geo-spatial 

mapping  services 


•  Postgres/Postgis 

The  postgres  relational  database  with  the  PostGIS33  spatial 
database  engine  is  currently  the  preferred  open  source  solution  for 
layering  attributed  geospatial  data  in  more  complex  systems. 
Several  commercial  companies  provide  support  and  technical 
services  for  this  project.  In  effect,  Postgis  "spatially  enables"  the 
PostgreSQL  relational  server,  allowing  it  to  be  used  as  a  backend 
spatial  database  for  geographical  information  systems  (GIS),  much 
like  ESRI’s  SDE  or  Oracle's  Spatial  extension.  PostGIS  follows  the 
OpenGIS  "Simple  Features  Specification  for  SQL"34. 


33  http://postgis.refractions.net/ 

34  http://www.opengeospatial.org/docs/99-049.pdf 
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LAMP  Stack 


LAMP35  is  an  acronym  for  Linux  Apache  MySql  (PHP/Perl/Python) 
integrated  services.  This  standardized  "stack"  of  open  source 
technologies  enables  robust  web  based  information  services.  Many 
applications  services  have  been  built  on  top  of  the  LAMP  stack. 
Integration  of  these  capabilities  into  government  projects  and 
activities  will  provide  significant  benefits  for  information-based 
services.  LAMP  represents  the  open  source  web  platform.  Most 
importantly,  LAMP  is  the  platform  of  choice  for  the  development  and 
deployment  of  high  performance  web  applications.  It  is  solid  and 
reliable. 36 


DoD  Contractors  and  Industry 

In  the  next  year  we  will  actively  engage  various  contractors  who 
work  for  DoD.  A  majority  of  contractors  are  using  open  source 
systems  internally  and  a  few  are  actively  supporting  public  open 
source  projects.  Our  goal  will  be  to  enlist  the  community  to  make 
open  source  part  of  their  business  activities.  A  key  element  of  these 
discussions  is  to  underscore  that  OTD  is  not  an  effort  to  undermine 
defense  contractors,  nor  an  ideological  movement  along  the  lines  of 
the  Free  Software  Foundation.  Rather,  it  is  a  set  of  business 
processes  that  supports  a  commercially  validated  business  model 
for  software  services.  In  the  shift  from  business  as  usual  to  OTD, 
there  are  greater  incentives  for  companies  that  are  able  to  be 
innovative  and  agile.  Part  of  the  OTD  communications  campaign 
will  be  to  engage  companies  (large  and  small)  who  are  willing  to 
respond  to  those  incentives. 


4.  Marketing  and  Evangelism 

Open  technology  development  is  more  than  just  technology;  it 
includes  changes  in  how  systems  are  acquired.  As  such,  education 
within  DoD,  the  US  government,  industry  and  Congress  is 
paramount.  Specifically  the  OTD  projects  needs  to: 

•  Publicize  Program 


35  http://www.onlamp.eom/pub/a/onlamp/2001/01/25/lamp.html 

36  http://www.onlamp.com/ 
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•  Distribute  Reports 

•  Develop  community  and  network 

•  Sell  OTD  within  DoD  and  educate  senior  leadership  and 
Congress 

•  Gather  Stories  from  AS&C  and  OS  Advocates 

These  efforts  include  creating  a  website  and  other  materials.  The 
OTD  effort  also  needs  to  coordinate  with  other  DoD  organizations 
such  as  JFCOM,  the  Combatant  Commands  and  the  Services. 

The  OTD  transition  team  will  network  with  other  organizations, 
resources,  champions,  and  change  agents.  Formal  relationships  will 
be  recommended  and  established  with  these  entities  to  leverage 
efforts  where  possible.  In  some  cases,  these  formal  relationships 
will  present  opportunities  to  demonstrate  inter-agency  collaboration 
and  the  benefits  of  the  OTD  approach.  Those  activities  should  be 
highlighted  and  pursued  where  possible. 


5.  Formalization  and  Operations 

The  goal  of  the  OTD  transition  team  is  to  change  the  default 
behavior  of  development  and  acquisitions  projects.  The  approach 
will  be  to  modify  current  system  requirements,  policies  and 
procedures.  These  changes  will  need  to  be  formalized  and 
embedded  into  the  current  system,  beginning  with  AS&C  and 
eventually  expanding  into  other  organizations.  Where  practical,  the 
team  will  create  and  encourage  formal  relationships  with  resources 
and  organizations  that  will  support  the  change. 


OTD  Planning  Activity  and  Formal  Reports 

An  OTD  Planning  Activity  should  be  established  to  oversee  and 
coordinate  transition  efforts  for  AS&C.  The  current  roadmap 
planning  team  augmented  with  additional  technical  support  will 
provide  the  baseline  for  FY06  activities.  The  transition  activities  will 
require  ongoing  review  and  adjustment.  The  team  will  be 
responsible  for  day-to-day  coordination  of  the  transition  effort, 
reporting  to  AS&C. 

Formal  status  and  reports  will  be  generated  during  the  transition 
process.  These  reports  will  document  the  lessons  learned  and 
provide  recommendations  for  future  efforts.  One  of  the  prime  areas 
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of  focus  will  be  identifying  processes,  procedures,  and  reviews  that 
will  need  to  be  modified  to  support  OTD  efforts.  Additional 
recommendations  will  be  documented  for  the  generation  and 
approval  of  program  requirements  for  future  projects  and 
acquisitions. 

Shared  Web- Based  Resource  for  OTD  Community 


The  OTD  team  will  establish  a  web  site  equipped  with  open-source 
collaborative  tools  to  aggregate  knowledge  and  seed  connections 
among  OTD  developers,  program  managers,  customers  and 
curious  DoD  personnel  getting  their  proverbial  feet  wet.  While  not  a 
comprehensive  IT  architecture  or  metadata  indexing  regime  for  all 
open-source  across  DoD,  the  OTD  site,  sponsored  by  AS&C,  will 
go  a  long  way  towards  establishing  a  marketplace  of  ideas  and  a 
user-created  repository  of  OTD  lessons  learned.  In  addition,  it 
enables  the  loosely  coupled  cross-linking  of  existing  OTD 
repositories  within  DoD  via  social  networking  (i.e.  an  index  of  OTD 
projects  with  descriptions  and  contact  information)  in  the  absence  of 
a  centralized  .mil  software  repository  (which,  given  .mil  IT  policy 
and  turf  wars,  may  never  exist),  while  fostering  a  ready-made  user 
population  for  more  formal  IT  repositories  as  OTD  scales  across 
DoD. 

Establish  Review  Gates  and  Embedded  Process 

A  combination  of  OTD  requirements,  reviews,  processes  and  gates 
will  need  to  be  defined  and  integrated  into  the  current  AS&C 
program  selection  and  review  process.  The  goal  is  to  institutionalize 
OTD  behavior  into  the  technology  integration  and  development 
efforts.  One  example  would  be  adding  OTD  criteria  to  the  Software 
Resources  Data  Report.  An  example  of  levers  in  the  process  is  to 
use  already  generated  reports  (like  DD  Form  2630  Software 
Resources  Data  Report  or  SRDR37)  to  influence  how  DoD  projects 
are  rated  and  ranked  according  to  how  they  use  promulgate  OTD 
methods. 

Business  Model  Study 


37  http://dcarc.pae.osd.mil/srdr/srdr_ch4_rfp_020204.doc 
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Business  model  analysis  to  develop  recommendations  and  a 
business  transition  plan  for  government  contractors  from  current  to 
OTD  practices.  This  study  is  planned  for  the  first  phase  allowing 
plan  recommendations  to  be  initiated  in  the  mid  term  phase. 

Legal  Study  &  Review 

A  detailed  legal  study  on  the  issues  involving  open  source, 
intellectual  property,  copyright,  US  government  law  and  contracting 
needs  to  be  coordinated.  AS&C  can  be  a  nexus  for  the  coordination 
and  assembly  of  legal  knowledge  and  groundwork  (e.g. 
documentation  of  methods  to  harmonize  DoD  IP  with  various  open 
source  software  licenses)  that  are  relevant  to  the  Services  as  well 
as  OSD. 

OTD  Playbook  for  Program  Managers  and  Contracting  Officers 

One  of  OTD’s  hurdles  within  DoD  is  the  trepidation  of  program 
managers  and/or  contracting  officers  who  are  unfamiliar  with  OTD 
and  therefore  a)  are  reluctant  to  change  their  business  practices  for 
fear  of  running  afoul  legally  or  contractually  and  b)  are  easily 
intimidated  by  vendors  who  make  sweeping  but  unfounded 
statements  about  the  IP  and  security  implications  of  open  source. 
The  OTD  team  will  produce  and  distribute  simple,  easy-to- 
understand  OTD  playbooks  for  program  managers  and  contracting 
officers  (possibly  in  conjunction  with  DAU)  to  equip  DoD  personnel 
with  the  knowledge  to  implement  OTD  business  processes  with 
confidence  on  the  legal  and  policy  front. 

AS&C  Advisory  Board 

A  formal  advisory  group  is  proposed  for  the  AS&C  Open  Source 
Software  and  Methodologies  project. 

The  group  will  provide  advice  and  ideas  about  how  to  move  open 
technology  development  methodologies  through  DoD.  Duties  and 
responsibilities  might  include: 

•  Review  material  generated  by  the  project  team 

•  Advise  the  OTD  Team  and  AS&C  on  strategy 

•  Facilitate  contacts  with  champions  within  and  outside  DoD 

Interactions  will  be  accomplished  via  email,  online  collaboration  and 
in  person  interviews.  Currently  no  formal  meetings  are  planned,  but 
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future  needs  may  entail  a  formal  meeting.  If  so  costs  of  travel  would 
be  paid  for  by  the  project. 

OTD  Project  Phases 

Implementation  will  proceed  in  three  phases: 


Activity  Name 

Start 

Finish 

2006 

2007 

Date 

Date 

J 

F 

M 

A 

M 

J  J 

A  S  O  N  D 

J 

F 

M 

A 

M 

J  J 

A  S 

O 

N 

D 

OTD  Nea'  Tern 

1/9/06 

6/23/06 

OTD  Me  Term 

7/10/06 

12/29/06 

> 

OTD  Lorg  Term 

1/8/07 

12/21/07 

Figure  10  OTD  Implementation  Phases 
Near  Term  Goals,  First  half  of  FY06 

Near  term  goals  will  focus  on  activities  that  are  under  the  control  of 
AS&C  and  parallel  efforts  with  external  open  source  software 
initiatives  within  the  government.  Resources  and  activities  will  be 
prioritized  on  projects  that  demonstrate  the  advantages  of  the  new 
approach  and  allow  open  source  methodologies  and  practices  to 
flourish.  Projects  will  be  encouraged  to  engage  “non-traditional” 
open  source  software  companies  and  communities  for 
implementation  expertise.  AS&C  will  implement  financial  incentives 
to  participating  projects  and  participating  contractors.  AS&C  and  the 
OTD  team  will  prioritize  evolutionary  planning  for  mid-term  and 
long-term  efforts.  The  OTD  team  will  establish  initial  relationships 
with  other  related  activities  and  organizations.  Success  in  the  near- 
term  requires  that  the  OTD  team  achieves  the  following  objectives: 

•  Understand  the  existing  OTD  skills  within  a  project 

•  Experiment  in  a  politically  low-risk  environment,  with  open 
source  of  the  appropriate  maturity  applied  to  well-understood 
requirements 

•  Gradually  build  OTD  skills  within  the  project  -  start 
with  outside  expertise 

•  Institutionalize  those  skills 

•  Work  with  Montana  State  University  for  OTD  repository  and 
analysis  of  software 

•  Increase  adoption  of  open  source  as  opportunities  arise 

•  Demonstrate  on  currently  funded  ACTDs,  JCTDs,  and 
Coalition  Activities.  Near  term  focus  will  place  emphasis  on 
getting  key  AS&C  projects  on  board  with  OTD  practices. 
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The  Short-term  tasks  include: 


•  Project  Support:  provide  a  minimum  level  of  project  support 
(web-hosting,  etc.). 

•  Build  and  Distribute  an  OTD  handbook  for  project  leads. 

•  Support  at  least  3  projects;  focus  on  those  projects  that  cut 
horizontally  across  various  DoD  missions. 

•  Find  one  major  program  that  will  commit  to  OTD. 

•  Education,  involvement  and  training  plan:  execute  education 
plan  for  the  greater  DoD  community 

o  Website  development  (classified  and  unclassified), 
o  Creating  collateral  material, 
o  Speaking  at  conferences. 

•  Educate  ACTD  program  managers. 

•  Educate  Congress  on  the  merits  of  OTD. 

•  Have  GAO  publish  reaction  to  OTD. 

•  Develop  relationship  with  the  Defense  Acquisitions 
University.  Find  champions  to  push  message. 

•  Develop  small  Industry  support  group. 

•  Publicity:  place  editorials  and  stories  in  DoD  journals. 
Develop  material  for  national  publications. 

•  Submit  report  to  Congress  for  comment  from  GAO 

•  Initiate  a  study  on  how  to  transition  the  business  model 

We  anticipate  the  short-term  plan  shall  last  six  months  and  will  also 
include  refinement  of  medium  and  long  term  plans.  Specific  goals 
within  this  timeframe  include: 

Demonstration  and  Metrics 

•  Apply  OTD  to  cooperating  projects 

•  Prioritize  and  challenge  opaque  implementations 

•  Gather  and  report  metrics 

•  Carrot  and  Stick  begins 

•  Business  Model  Demonstration  and  study 

•  Geo-spatial  Replacements 

•  IT  and  communication  infrastructure 

Resources  and  Support 

•  OTD  Web  Site 

•  Participation  in  relevant  conferences 
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•  Informal  collaboration  with  external  resources 

•  Technical  Support  in  advising  projects 

Marketing  and  Communication 

•  Coalition  Activities 

•  Start  working  Requirements,  Process,  and  Gates 

•  Letter  of  intent  to  all  projects 

•  OTD  Meetings  with  managers  and  teams 

Formalization  and  Operations 

•  Leverage  related  activities 

•  Press  releases  and  briefings 

•  Advisory  Board  review 

•  Kick  off  Business  Plan  Study 


Mid-Term  Goals 

Embed  new  OTD  requirements,  review  gates  for  FY07  Approval 
and  review  cycle. 

During  the  second  phase  we  will  continue  to  support  and  expand 
AS&C  OTD  related  projects  while  continuing  to  formalize 
relationships  with  external  organizations,  champions  and  resources. 
The  main  objective  of  this  phase  will  be  to  insert  requirements, 
process,  metrics,  and  review  of  OTD  practices  into  the  AS&C 
project  approval  cycle.  Formalization  through  the  system  will  begin 
to  encourage  default  OTD  behavior. 

Mid  term  goals  will  be  pursued  starting  in  the  second  half  of  FY06. 
Concrete  steps  for  AS&C  during  this  period: 

■  Modify  review  and  approval  process  for  FY07  projects, 

■  Insert  OTD  requirements,  metrics,  processes  and  procedures 
that  will  be  used  in  the  selection  process.  - 

■  Conduct  additional  expansion  and  demonstration  of  these 
practices  into  other  ACTD  and  JCTDs 

■  Demonstrate  of  the  benefits  of  these  activities  on  coalition 
activities 

■  dentify  and  pursue  of  a  Defense  Challenge  Program  initiative 
based  on  open  source  approaches  will  be  some  of  the 
highlights  of  this  phase. 
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One  of  the  key  goals  during  this  phase  will  be  a  robust  business 
case  study  that  provides  recommendations  on  how  to  transition 
from  the  current  acquisition  structure  to  the  new  practices  on  major 
DoD  programs. 

During  this  phase  we  will  also  begin  to  organize  objectives  in  the 
following  key  areas: 

■  Open  source  repositories  within  DoD  programs  and  projects 

■  Leverage  of  external  Open  Source  resources  into  the 
infrastructure  and  programs 

■  Application  of  this  approach  to  hardware  design  and  specialized 
systems  with  smaller  communities  of  interest. 

Mid-term  focus  includes: 

•  Project  support:  increase  the  number  of  projects  supports  by 
an  order  of  magnitude 

•  Develop  plans  to  establish  an  OTD  government  support 
center. 

•  Create  DoD  guidance  group  for  how  to  use,  reuse  and 
develop  OS  software  and  hardware. 

•  Education,  community  development  and  training  plan: 
building  upon  the  previous  plan,  gather  case  studies  and 
publicize  within  DoD. 

•  Visit  combatant  commands 

•  Examine  how  to  connect  DoD  source  site  to  that  of  the 
greater  US  government.  Continue  to  document. 

•  Industry  Support:  scale  industry  support  group. 

•  Publicity:  continue  conference-meeting  attendance. 

■  Plan  for  DoD  open  source  conference/meeting. 

Specific  goals  within  this  timeframe  include: 

Demonstration  and  Metrics 

•  Gather  metrics  and  success  stories  on  projects 

•  Evolve  support  to  AS&C  projects 

•  Recognition  for  early  adopters 

•  Focus  on  a  showcase  coalition  activity 

Resources  and  Support 
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•  Demonstrate  resource  sharing  between  projects 

•  Define  plan  for  long  term  OTD  support  infrastructure 

•  Build  initial  project  hosting  website 

•  Core  OSS  Technical  Support 

•  Marketing  and  Writing  Support 

Marketing  and  Communication 

•  Brief  New  FY07  projects  and  candidates  on  OTD 

•  More  Stick  as  counterpoint  to  Carrot 

Formalization  and  Operations 

•  Establish  OTD  requirements  and  guidelines 

•  Begin  to  impact  reviews  with  OTD  checks 

•  Formalize  “Lock  In”  evaluation  system 

•  Identify  Regulatory  and  Acquisitions  obstacles 

•  Deliver  Business  Plan  Study  (Deliverable) 

•  First  Year  Report  (Deliverable) 


Long  Term  Goals 

For  the  FY07  timeframe:  The  Long-term  goals  will  apply  the  results 
of  the  previous  phases  towards  changing  the  culture  and  processes 
associated  with  technology  development  on  major  acquisitions 
programs.  The  results  of  the  previous  activities  and  business 
studies  will  be  reviewed  and  applied  towards  these  objectives.  The 
success  condition  of  this  phase  is  that  OTD  technology 
development  processes,  resources,  tools  and  methods  are  applied 
by  default  when  acquisition  programs  are  built  and  implemented. 

•  Analyze  and  improve  the  process 

•  Create  Supporting  Infrastructure 

•  Export  the  processes  and  methods.  (FY07) 

•  Translate  AS&C  success  stories  outside  of  AS&C. 

•  Demonstrate  interagency  collaboration 

•  Start  to  influence  larger  DoD  processes 

•  Showcase  to  high-level  government  decision  makers. 

Long-term  focus  includes: 
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•  Project  support:  complete  transition  of  website(s)  to  DoD 
organization. 

•  Education,  involvement  and  training  plan:  continue  to 
publicize  the  program  and  ideas. 

•  Publicity:  continue  conference-meeting  attendance.  Plan  for 
DoD  open  source  conference/meeting.  Create  a  list  of 
success  stories  (public  and  private) 

•  Create  champions  list,  public-private  -  people,  companies, 
congress 

•  Create  awards  for  code  reuse  of  code  by  companies? 

•  Formulation  of  OTD  security  and  governance  policies. 

Specific  goals  within  this  timeframe  include: 

Demonstration  and  Metrics 

•  Target  Major  Cross  Agency  collaboration  e.g.  NASA  and 
DoD  using  same  OSS  code,  both  contributing  to 
development 

•  Expand  AS&C  Project  Participation 

•  Expand  Coalition  Project  Participation 

Resources  and  Support 

•  Begin  to  implement  OTD  support  Infrastructure 
Marketing  and  Communication 

•  Showcase  to  Government  Decision  Makers 
Formalization  and  Operations 

•  Begin  to  modify  external  requirements,  reviews,  and 
processes 

Formulation  of  OTD  Security  and  Governance  Policies 

As  part  of  next  years  plan,  the  OTD  team  will  review  and  make 
recommendations  about  how  to  deal  with  security  issues  and  open 
source  software.  Currently  there  is  a  Defense  Science  Board  study 
being  conducted  to  review  DoD  policy  on  this  matter.  We  anticipate 
utilizing  their  guidance  on  the  issues. 

These  issues  include: 
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•  How  to  deploy  a  development  environment 

•  Classified  versus  unclassified  versus  compartmentalized 

•  Vetting  centers  for  getting  OS  into  DoD 

•  Search  across  a  number  of  OS  libraries 

•  Code  fork  issues 
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OTD  for  Senior  Leadership 

Senior  leadership  will  need  to  constantly  reinforce  and 
communicate  the  vision  and  benefits  of  Open  Technology 
Demonstration.  They  will  need  to  provide  the  resources,  flexibility, 
and  top  cover  that  will  allow  innovative  implementers  to  flourish.  To 
guide  the  initial  transition  a  dedicated  OTD  government  transition 
manager  should  be  hired  or  designated  to  coordinate  the  efforts  of 
the  team.  When  challenges  inevitably  arise  from  the  status  quo, 
that  person  can  block  and  tackle  from  inside  the  building. 

Senior  Leadership  will  need  to  define  and  implement  changes  to  the 
current  review  and  approval  process  to  establish  new  requirements, 
processes,  procedures,  and  gates  that  embed  OTD  practices  into 
the  infrastructure. 

Initially,  senior  leadership  will  need  to  seek  out  talented  change 
agents  and  innovators  to  spearhead  the  first  projects.  These  teams 
will  need  the  support  of  upper  management,  the  flexibility  to 
experiment  and  even  fail  as  they  system  adapts.  AT&L’s  OTD 
leadership  should  foster  an  environment  that  allows  and  rewards 
teams  that  take  reasonable  risk  for  large  potential  gains. 

As  the  metrics  are  developed  and  success  stories  accumulate, 
management  will  be  able  to  ratchet  technology  collaboration  up  to 
the  next  level  and  seek  out  interagency  projects. 

Finally,  with  any  transition,  there  are  system  anti-bodies  that  will 
attempt  to  stifle  change.  The  OTD  transition  can  expect  challenges 
from  bureaucratic  forces  in  legal,  acquisitions,  and  security 
organizations.  Entities  that  have  become  successful  within  the 
current  practices  will  see  OTD  as  a  threat  and  attempt  to  subvert  it. 
Senior  leadership  will  be  challenged  to  navigate  through  these 
obstacles  in  order  to  realize  the  benefits  of  OTD  business  process 
with  and  across  programs  and  organizations. 
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OTD  for  Program  Managers 

Open  Technology  Development  will  present  new  challenges  and 
rewards  for  Program  Managers.  A  successful  program  manager 
must  manage  the  schedule,  resources,  and  interfaces  for  the 
activity  in  question.  During  implementation,  most  program 
managers  will  guard  against  requirements  creep,  strive  to  insure  the 
developers  remain  confined  to  their  tasks,  work  problems  as  they 
arise,  and  hopefully  deliver  what  was  promised  within  cost  and  on 
schedule. 

But  often,  changes  are  forced  on  the  project.  These  changes  can 
be  the  result  of  new  technological  advances,  changing  external 
environments,  new  people,  or  changes  in  user  needs.  The  larger 
the  project  and  timeline,  the  more  likely  the  need  for  change  during 
implementation.  These  changes  are  often  disruptive  and 
unwelcomed  by  the  team,  and  lead  to  conflicts  with  the  PM  pitted 
between  a  restive  end-use  community  and  a  project  spiraling  out  of 
control. 

Programs  often  struggle  to  deliver  their  requirements  and  seldom 
outperform  initial  estimates.  Approaches  such  as  rapid  prototyping 
and  spiral  development  have  emerged  in  recent  years  to  address 
the  need  for  evolution  during  implementation.  Open  standards  and 
interfaces  have  begun  to  modularize  and  simplify  overall  system 
complexity.  Open  source  implementations  often  bring  new 
functionality  within  range  of  the  project  and  many  implementation 
decisions  can  safely  made  within  lower  levels  of  the  organization. 
Successful  adoption  builds  a  community  of  interest  that  includes 
managers,  users,  developers,  and  key  decision  makers  on  a 
collaborative  team. 

Open  Technology  Development  practices  are  agile,  opportunistic, 
and  are  well  suited  for  dynamic  environments.  In  this  capacity,  they 
provide  a  new  set  of  tools  and  controls  for  program  managers  in  the 
face  of  shifts  in  technology  and  customer.  Properly  implemented, 
an  OTD  approach  involves  all  parties  in  the  difficulties  and 
opportunities  that  will  present  themselves  in  the  design  and 
implementation  process.  This  leads  to  team  “buy  in”  and  less 
contention  between  the  various  parties  involved.  OTD  certainly  has 
the  potential  to  dramatically  reduce  the  cost  of  adding  functionality 
to  a  program.  It  also  presents  the  opportunity  to  add  “pleasant 
surprises”  as  the  latest  advances  in  systems  and  technologies  can 
be  added  to  the  solution. 

The  collaborative  technologies  will  enable  all  participants  to  take  an 
active  role  in  the  development  process  while  the  program  manager 
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assumes  the  role  of  “benevolent  dictator”  to  minimize  serious 
conflict  and  guide  the  best  overall  solution. 


OTD  for  Developers 

There  is  evidence  that  developers  will  be  strong  supporters  of  an 
OTD  approach.  Many  have  already  experienced  the  benefits  of 
open  source  software  collaborative  techniques  which  are 
proliferating  on  the  internet.  Developers  have  also  experienced 
some  of  the  frustrations  that  are  typical  of  a  hierarchically  managed 
top  down  approach. 

The  transition  path  for  developers  and  implementers  should  focus 
on  increasing  proficiency  in  open  source  software  skills, 
researching  and  participating  in  relevant  projects,  and  helping  to 
identify  barriers  to  adoption  of  these  practices  within  their 
government  projects.  The  transition  will  depend  on  internal 
champions  to  educate  and  identify  changes  that  will  be  needed  for 
efficient  collaboration  and  OTD  practices. 

During  implementation,  developers  will  be  crucial  in  assessing  the 
maturity  and  applicability  of  available  open  solutions  and  projects. 
Ideally,  technology  staff  will  be  at  the  forefront  of  technical 
implementation  decisions,  but  must  also  understand  the  larger 
implications  of  those  decisions:  a  good  design  will  not  just  solve  the 
problem  at  hand,  but  will  be  leveragable  by  other  projects  and 
programs.  License  fees,  training,  maintenance,  and  system 
flexibility  are  factors  that  the  development  staff  will  have  to  consider 
as  implementation  decisions  are  made.  Open  standards  and 
interfaces  will  allow  a  program  to  evolve  and  improve  over  its  life 
cycle.  Open  versus  closed  implementations  will  have  dramatic 
impact  on  the  life  cycle  costs  for  the  system. 

With  OTD,  developers  have  an  opportunity  to  exert  more  control 
over  design  details,  but  they  also  take  on  additional  responsibilities 
for  that  design.  Successful  OTD  developers  will  demonstrate 
collaborative  communication  skills  within  the  community  of  interest. 
This  implies  effective  communication  with  members  of  widely 
varying  technical  backgrounds  and  interests  in  the  system.  This 
networking  of  loosely  coupled  individuals  and  organizations,  in  turn, 
accelerates  cultural  shifts  which  further  enable  the  dissemination  of 
OTD  business  processes  across  the  enterprise. 
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OTD  for  Transition  Managers 

Transition  Managers  have  a  vested  interest  in  the  success  of  the 
OTD  approach.  Historically,  the  most  difficult  phase  in  any  system 
transition  is  from  technical  prototype  to  operational  implementation. 
The  worst  scenario  is  when  a  large  complex  system  is  developed 
and  modified  over  a  long  period  of  time  without  significant  input 
from  the  users  of  the  system.  Even  when  there  is  significant 
operational  participation  in  the  requirements  definition  phase  - 
changing  environments,  mission  requirements,  and  technological 
advances  can  render  the  delivered  system  obsolete. 

OTD  provides  a  mechanism  to  involve  operations  in  an  interactive 
community  of  interest  as  the  system  evolves  through  rapid 
technology  spirals.  Currently,  systems  try  to  address  this  problem 
through  user’s  conferences  or  testing  phases.  While  these 
meetings  and  milestones  are  a  step  in  the  right  direction,  they  can 
not  compare  to  an  effective  online  community  of  interest. 
Collaborative  tools  provide  a  mechanism  to  provide  a  tighter 
coupling  between  real  world  users  and  the  technology 
implementers  as  the  system  iterates  on  ideal  solutions.  When  well 
run,  the  community  of  interest  acts  as  a  team  with  a  common  goal 
versus  groups  with  competing  interests. 

As  a  Transition  Manager,  an  important  consideration  will  be  the  life 
cycle  costs  of  the  system.  Open  systems  approaches  with  standard 
interfaces  and  highly  leveraged  technology  components  will  present 
more  options  for  systems  evolution  and  support.  Some  of  the  same 
collaborative  tools  and  resources  can  easily  transition  into  the 
support  mechanism  for  the  delivered  system. 
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OTD  for  Contractors 


Established  government  contractors  face  some  of  the  most  difficult 
challenges  in  the  Open  Technology  Development  transition.  Over 
the  years,  successful  government  contractors  have  optimized  and 
adapted  their  policies  and  procedures  to  the  current  system.  Cost 
plus  contracts,  requirements  based  procurements,  and  intellectual 
property  rights  have  been  tuned  to  create  successful  business 
models  within  the  structure  imposed  by  government  rules  and 
regulations. 

OTD  requires  a  shift  from  emphasis  on  intellectual  property  and 
products  to  professional  services  and  open  collaboration.  During 
the  first  year  of  transition,  the  government  will  place  emphasis  on  a 
business  model  transition  study  that  encourages  the  new  practices. 
Early  adopters  will  gain  increased  exposure  and  will  be  able  to 
strategically  position  themselves  for  the  future  through  successful 
demonstration  of  OTD  results. 

Appropriate  financial  models  and  rewards  need  to  be  structured  for 
this  behavior.  In  the  end,  the  government  will  establish  the 
requirements  and  successful  government  contractors  will  adopt  and 
adapt  to  the  new  practices. 

The  team  will  cultivate  OTD  champions  within  the  contractor 
community  to  open  up  systems  interfaces,  change  system 
administration  policies  to  allow  online  collaboration,  and 
demonstrate  rapid  technology  implementations  with  open  source 
technologies. 

Contractors  who  take  this  approach  should  benefit  from  a  more 
integral  role  within  collaborative  teams.  As  technology  continues  to 
evolve  as  a  commodity  they  will  have  a  competitive  advantage  in 
demonstrating  customer  oriented  professional  services  and  domain 
expertise. 
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3.  Recommendations 


This  roadmap  effort  proposes  a  transition  to  Open  Technology 
Development  practices  in  the  Department  of  Defense  initially 
focusing  on  the  projects  and  activities  within  AS&C.  Success  is 
achieved  when  policies,  procedures,  requirements  and  practices 
establish  open  source  software,  open  interfaces  and  systems,  and 
collaborative  technology  methodologies  as  the  default  baseline. 
This  will  occur  after  the  correct  checkpoints,  reviews,  and  policies 
are  evolved  towards  those  objectives.  Once  established  within 
AS&C,  those  processes  should  be  spread  to  larger  programs  and 
acquisitions  using  the  metrics  and  information  gathered  along  the 
way. 

To  accomplish  these  objectives  the  following  recommendations  are 
made  by  the  roadmap  planning  team: 

1 .  Create  an  OTD  strike  team  to  oversee  and  guide  transition 
efforts 

2.  Establish  formal  relationships  with  external  activities 
promoting  this  approach 

3.  Initially  focus  on  AS&C  projects,  open  the  solutions,  gather 
metrics 

4.  Establish  Review  gates,  policies  and  processes  to  reinforce 
the  new  behavior  for  the  FY07  approval  cycle 

5.  Network  and  communicate  these  efforts  externally 

6.  Create  an  AS&C  Advisory  Board  to  review  Open  Technology 
Development  material  and  activities 

Recommendation  1 :  Approve  and  Fund  an  OTD  Strike  Team 

The  OTD  Strike  Team  would  include  the  current  roadmap  team 
augmented  with  technical  support  for  evaluating  projects  and 
construction  of  the  OTD  Wiki  and  online  infrastructure.  This  team 
will  be  initially  funded  out  of  the  Large  Data  JCTD  as  part  of  the 
effort  to  introduce  open  source  geospatial  capabilities  into  the 
project.  The  team  will  coordinate  with  additional  ACTDs  and  JCTDs 
and  establish  separate  efforts  through  those  projects.  Nominally, 
the  ACTD  or  JCTD  would  provide  the  additional  funding  to  support 
open  technology  implementation.  In  some  cases,  additional  funding 
may  be  required  to  "challenge"  an  embedded  implementation.  In 
those  cases,  project  plus-ups  may  be  required  to  support  the 
challenge. 
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Senior  Leadership  Role 

As  mentioned  previously  AS&C  should  take  a  central  role  in 
organizing  ORD  activities.  It  is  recommended  that  AS&C  focuses  on 
internal  and  external  communications  supporting  the  OTD  benefits 
and  transition.  AS&C’s  OTD  point  person  would  be  in  the  position  to 
draft  letters,  policy  statements,  and  news  stories  that  talk  about 
both  the  need  and  implementation  for  the  OTD  transition. 


Recommendation  2:  Establish  formal  relationships  with 
external  activities  promoting  this  approach 

Open  Source  Software  and  its  associated  collaborative 
technologies  have  already  been  internally  adopted  by  much  of 
corporate  America.  It  is  being  used  in  many  critical  operations 
within  government  agencies  as  evidenced  by  the  Open  Source 
Software  Institute  CRADA  with  the  Navy.  ASC’s  OTD  node  should 
collaborate  with  and  leverage  previous  activities,  policy  and  security 
investigations,  and  resources  to  accomplish  the  transition.  Open 
source  champions  should  be  networked  together  through  the  AS&C 
transition  efforts.  The  OTD  Strike  Team  will  establish  relationships 
with  these  entities  as  part  of  the  overall  process  of  formalizing  and 
embedding  these  methods  into  the  system  and  acquisition 
processes. 

Recommendation  3:  Focus  on  AS&C  Projects 

Initial  transition  efforts  should  focus  on  projects  and  programs  within 
AS&C.  The  projects  should  be  prioritized  based  on  the  ability  to 
demonstrate  the  advantages  of  the  OTD  approach.  This  will  include 
an  evaluation  of  the  open  source  technologies  that  can  be  quickly 
brought  to  bear,  the  willingness  of  the  project  team  to  participate, 
and  the  ability  to  gather  supporting  metrics. 

Prioritize  ACTDs  and  JCTDs 

The  OTD  Strike  Team  will  coordinate  with  the  decision  makers  and 
technical  staff  of  FY06  ACTDs  and  JCTDs.  Each  will  be  evaluated 
and  encouraged  to  participate  in  the  OTD  effort.  The  various 
projects  will  be  prioritized  based  on  the  applicability  of  OTD 
practices  to  the  proposed  solution.  Factors  will  include  initial 
development  costs,  long  term  operations  and  maintenance 
implications,  willingness  of  the  team  to  participate,  and  availability 
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of  open  source  resources  to  support  the  effort.  The  preferred 
approach  will  be  to  bring  in  outside  open  source  domain  expertise 
to  perform  critical  support  and  modification  functions  on  open 
technologies  with  the  support  of  the  existing  project  team.  It  is 
anticipated  that  there  will  varying  degrees  of  participation.  Ideally, 
open  systems  design  with  standards  based  interfaces  will  be 
applied  to  the  solutions.  Other  projects  may  provide  individual 
functions  or  services  with  open  technologies  in  lieu  of  proprietary 
alternatives.  Finally,  there  may  be  cases  where  open  technology 
options  are  pursued  as  competitors  to  existing  closed 
implementations. 

Gather  Metrics 

Metrics  and  analysis  will  need  to  be  gathered  and  updated  to 
support  the  transition.  Part  of  the  effort  will  be  researching  and 
networking  with  other  efforts  to  gather  previous  analysis.  The 
implementation  efforts  with  the  ACTDs  and  JCTDs  will  provide  an 
additional  source  of  information  that  will  be  analyzed  to  gather 
benefits  and  concerns  with  the  approach.  The  underlying  transition 
is  expected  to  be  challenging  and  the  team  will  need  to  remain 
flexible  and  responsive  during  the  initial  demonstrations. 


Recommendation  4:  Establish  Review  gates,  policies  and 
processes  to  reinforce  the  new  behavior  for  the  FY07  approval 
cycle 

Recommendation  5:  Network  and  Communicate  Vision  to 
External  (to  AS&C)  Agencies  and  Initiatives 

The  OTD  transition  is  consistent  with  external  initiatives  and  should 
be  linked  with  those  efforts  when  possible: 

•  SecDef  is  being  briefed  every  month  about  how  DoD  can 
shrink  the  force  (by  lowering  workload.  OSS  is  something  to 
brief  to  him  on  and  benefits)  [See  page  27]. 

•  2002  defense  bill  -  entitlements  are  $4  billion  in  2009  it  will 
be  $20  billion.  Need  to  do  more  with  less 

•  Defense  Business  Transformation  Efforts 

•  Initiatives  emphasizing  networking  vs.  hierarchical  control 
structures 

•  Disruptive  technology  evaluations 
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The  OTD  transition  team  will  network  with  other  organizations, 
resources,  champions,  and  change  agents.  Formal  relationships 
with  these  entities  will  be  recommended  and  established  these 
entities  to  leverage  efforts  where  possible.  In  some  cases,  these 
formal  relationships  will  present  opportunities  to  demonstrate  inter¬ 
agency  collaboration  and  the  benefits  of  the  OTD  approach.  Those 
activities  should  be  highlighted  where  possible. 


Recommendation  6:  AS&C  OTD  Advisory  Board 

As  the  planning  and  transition  activities  progress,  we  will  depend  on 
the  advice  and  guidance  of  national  experts  on  the  AS&C  OTD 
Advisory  Board.  An  initial  list  of  candidates  has  been  contacted  and 
appears  in  this  report.  The  advice  of  this  board  will  be  invaluable  in 
how  to  use  the  existing  system  to  meet  our  objectives.  By  imposing 
new  requirements  and  seeking  long-term  operations  and 
maintenance  accountability  within  the  design  phase,  we  intend  to 
transition  the  default  behavior  to  open  systems  design.  It  will  be 
necessary  to  structure  appropriate  reviews  and  metrics  while 
working  within  the  existing  culture  will  be  critical  to  success.  The 
formalization  of  a  well-respected  advisory  board  will  be  one  of  the 
first  critical  steps  along  that  path. 
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Appendices 


Appendix  A  -  Meetings  and  Interviews 

List  of  a  few  of  the  interviews  performed  in  the  roadmap  study: 

•  Paul  Brinkley,  OSD,  Business  Transformation  Office 

•  Dale  Christensen,  SECNAV,  DON  CIO  Office 

•  Robert  Gold,  Associate  Director  for  Software  and  Embedded 
Systems,  OUSD  DDR&E/S&T 

•  John  Grosh,  OUSD  DDR&E/S&T 

•  James  Hoffman,  NRL 

•  Mike  Kreiger,  Director  Information  Management,  OASD(NII) 

•  Dardo  Kleiner,  NRL 

•  Mike  Knollman,  JCTD  Office 

•  Dick  Lee,  ACTD  Office 

•  Pat  Neher,  Navy  JAG 

•  Andy  Marshall,  OSD,  Office  of  Net  Assessment 

•  Dawn  Meyerricks,  VP-AOL 

•  Terry  Mitchell,  ACTD  Office 

•  James  O’Bryan,  The  O’Bryan  Group 

•  Chuck  Riechers,  OASD/NII 

•  Dr.  Chuck  Perkins,  ACTD  Office 

•  Sue  Payton,  AS&C  Office 

•  LTG  Robert  M.  Shea,  Joint  Staff,  J-6 

•  David  Scantling,  OSD,  Business  Transformation  Office 

•  Fritz  Schultz,  DISA 

•  John  Weathersby,  NCOSPR  Organization 

•  Lin  Wells,  OASD/NII 

•  Dennis  Wisnosky,  Wizdom  Systems,  Inc. 
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Appendix  B  -  Measuring  the  Maturity  of  Open  Source 


Maturity 

Immature 

Reasonably 

Very 

Criteria 

Criteria 

Mature 

Mature 

Description 

Product 

Criteria 

Age 

<  6  mos 

6  mos  -  2 
years 

>2  years 

OSS  efforts  that  are  just 
getting  underway  are  risky 
for  enterprises. 

Multiple 

Supported 

Platforms 

One 

Platform 

Many  related 
platforms 

Multiple 

heterogen 

eous 

platforms 

Products  that  work  on 
Windows  and  Unix  are 
most  desirable 

Momentum 

No  release 
in  last  6 
months 

<  two 

releases  in 
past  year 

Regular 

releases 

This  is  key  to  helping 
separate  vital  products 
from  ones  that  are 
withering 

Popularity 

Unknown 

product 

Viable 

alternative 

Category 

leader 

Popular  OSS  products  are 
well  tested  and  therefore 
more  mature.  They  are 
also  likely  to  be 
interoperable  with  a  large 
number  of  other  products 

Design 

quality 

Monolithic 

application 

Multiple 

components 

Well- 

defined 

API 

This  criterion  is  key  in 
determining  the  effort 
required  to  extend  and 
adapt  the  product. 
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Use 

Criteria 

Setup 

cost 

Poorly 
documented 
install  process; 
poor 

documentation; 
help  available 
from  developers 

Well 

documented 
install  process, 
reasonable 
documentation; 
help  available 
from  developers; 
help  available  in 
support  forum 

Well 

documented 
install  process; 
install 

wizards/scripts 
available; 
reasonable 
documentation; 
help  available 
from  developers; 
help  available  in 
support  forums; 
third  party  install 
services 

Most 
products 
should 
require  a 
setup  effort 
of  hours  or 
days,  not 
weeks  or 
months. 

Usage 

cost 

Poor  or  non¬ 
existent 
documentation; 
help  available 
only  through 
direct  contact 
with  developers 

User  manuals 
available;  help 
available  in 
support  forums 

Third  party 
training  services 
available 

This 

criterion  is 
often 

overlooked 

when 

evaluating  a 
product 

End- 

user 

support 

No  forums  or 
mailing  lists 

Some  forums  or 
mailing  lists 

Well-run  forums 
and  mailing  lists 
with  archives 
and  search; 
third-party 
support  options 

User 

community 
(forums, 
mailing  lists) 
and  third 
party 

support  are 
vital  to  a 
product’s 
success 

Figure  1 1  from  Open  Source  for  the  enterprise38 


38  Open  Source  for  the  enterprise,  Dan  Woods  and  Gautam  Guliani,  Copyright 
2005,  O-Reilly  Media 
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Appendix  C  -  Open  Source  Geo-spatial  capabilities 


Figure  12  OSSIM  advanced  3D  visualization 


The  Large  Data  JCTD  will  demonstrate  advanced  geo-spatial  capabilities 
with  the  OSSIM  software  suite. 

OSSIM  is  an  open  source  software  project  that  is  being  used  by  various 
national  laboratories  and  is  embedded  in  several  commercial  and 
government  solutions. 

Advanced  geo-spatial  web  services,  analysis  and  production  tools,  and 
accurate  three  dimensional  visualization  clients  will  be  demonstrated  and 
provided.  The  Large  Data  JCTD  will  demonstrate  remote  access, 
manipulation,  and  viewing  of  very  large  commercial  and  government  data 
sets. 

Additional  information  about  the  OSSIM  project  can  be  obtained  through 
the  Open  Source  Geospatial  Foundation  http://osqeo.org  or  directly  from 
the  OSSIM  project  site  at  http://www.ossim.org. 
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